Prototypes as UI tests

A prototype already says press this, arrive there. That is a test case. The useful part is that nobody wrote it: it came out of the design, and when the design changes the test changes with it.

How it works

A flow in the Design surface is a graph: screens, and transitions with an event and an action. Pathrule compiles that graph into a sequence of simulator actions and runs it against your app in the simulator.

Taps are resolved by accessibility identifier or by label, which is the second reason the design's node ids travel into the code at handoff: the same id that makes a fidelity comparison exact makes the tap unambiguous.

A hand-written UI test drifts. This one cannot.

A test written by hand describes the flow as it was on the day someone wrote it. The design moves, the test does not, and after a few months the suite is a record of an old product.

Here the flow and the test are the same object. Rewire a transition and the test takes the new route on its next run, because there is no second copy of the journey to keep in step.

An authoring problem is not a test failure

This is the rule that makes the report worth reading.

A graph with a screen nothing reaches, or a transition whose trigger has no visible control, is a design defect. Reporting it as "step 3 failed" teaches you to distrust the whole run, and a report you distrust is a report you stop opening.

So the flow is audited before it is executed, and those problems are reported as what they are: something to fix in the design, separate from what the app did when the flow was actually run.