What makes a swipe or drag case reproducible when direction and speed change the outcome?

## A swipe carries four things, not one A moving contact is described by where it starts, where it ends, how long it stays down, and — derived from those — how fast it travelled. Products branch on every one of them. - **Direction** picks between opposite behaviours. A leftward drag across a list row commonly reveals a destructive action; a rightward drag across the same row marks the item complete. - **Distance** decides whether the interaction commits or springs back. Row actions typically stick only past a commit threshold expressed as a fraction of the row's width; release short of it and the row animates home. - **Duration**, and therefore velocity, separates a *drag* from a *fling*. The same path traced slowly settles where the contact lifted; traced quickly it carries momentum, overshoots, and may dismiss the element entirely. - **Origin** changes meaning even when the other three are identical. A downward drag starting at the top of a scrollable list triggers a refresh; the same drag starting in the middle is ordinary scrolling. A drag starting at a screen edge may be claimed by the system before the application ever sees it. A case that says "swipe left on the row" has specified one of those four. The other three are filled in by whatever default the harness carries, and nothing in the source tells a reader which gesture actually ran. ## Why recorded coordinates do not travel The tempting shortcut is to capture the gesture once on the machine in front of you and replay the numbers. | How the case expresses the gesture | Survives a change of device? | What goes wrong | |---|---|---| | Absolute pixel start and end points | No | a different size or density puts an endpoint outside the element | | A fraction of the whole screen | Partly | the element's position within the screen moves with the layout | | A fraction of the target element's bounds | Yes | needs the bounds at run time, but the path stays inside the element | | A replay of one captured contact trace | No | freezes both the geometry and the timing of a single machine | The failure this produces is the confusing kind: the case is green on the machine that recorded it and red — or, worse, green for the wrong reason — everywhere else. Absolute endpoints encode one screen size, one density and one layout. On a narrower screen a fixed travel no longer clears a threshold that is a fraction of the row; on a wider one the same travel overshoots into a neighbouring behaviour. ## Velocity is a product parameter, not noise Teams treat duration as noise because it does not appear in the case's intent — "swipe the row away" says nothing about speed. The product's recogniser reads it anyway. A slow drag past the commit threshold and a fast flick along a shorter path can produce the same outcome, while a fast flick along the full path can produce a different one, because momentum carries the element past a second boundary. So choose the duration from the behaviour under test and name it: - a **settle** duration, long enough that the contact is unambiguously a drag, for cases about thresholds and reveal states; - a **fling** duration, short enough to carry momentum, for cases about dismissal and overscroll; - never the harness default, which is neither, and which changes when the tooling is upgraded. ## Making the gesture a value the case owns 1. Express endpoints as **fractions of the target element's bounds**, resolved at run time. "From ninety per cent of the row's width to ten per cent" means the same thing on every screen. 2. Pass the **duration explicitly** on every gesture, from a named constant rather than a literal buried in one case. 3. Put the direction and the intent in the **case name**, so a red result reads "dragging past the commit threshold reveals the delete action" rather than "swipe test 3". 4. Keep the gesture helpers in **one place** the whole suite calls. When a threshold moves, that is one edit rather than forty. 5. Cover **both sides of every threshold**: one case just past it that commits, one case short of it that springs back. A single mid-range value drifts to whichever side a given device lands on, and drifts silently. 6. Never tune the distance until the case turns green. A number chosen that way encodes the machine it was tuned on and nothing else. ## Assert the branch, not the motion The last mistake is asserting that the gesture happened rather than that the intended branch ran. "The row moved" is true of the commit and of the spring-back alike. Assert the outcome the direction and speed were chosen to produce — the destructive action is now offered, the item has left the list, the list refreshed — and write the sibling case for the branch you did not take. A pair of cases that differ in exactly one declared parameter and assert opposite outcomes is the clearest evidence that a case controls its gesture rather than inheriting it.