Your Prototype Is Already a UI Test. Run It.
Hand-written UI tests describe the product as it was the day somebody wrote them.
A test compiled from the prototype describes the product as it is designed today, by construction.
Short answer
A design flow is a graph of screens and transitions, which is exactly what a UI test case carries, so the flow itself can be compiled into simulator actions and run against the real app. Because the flow and the test are one object, rewiring a transition changes the test on its next run.
What this covers
- Because the flow and the test are the same object, rewiring a transition changes the test on its next run; there is no second copy of the journey to keep in step, which is how hand-written UI suites drift.
- Taps resolve by accessibility identifier or label, which is why carrying the design node id into the code pays twice: it makes a fidelity comparison exact and an automated tap unambiguous.
- The flow is audited before it is executed, and a design defect such as an unreachable screen or a transition with no visible control is reported as a design defect, never as a failed test step.
- That separation is what keeps the report trustworthy: a report that blames the app for an authoring mistake teaches people to stop opening it.
Before and after
| Area | A hand-written UI test | A test compiled from the flow |
|---|---|---|
| Where the journey lives | In the test file, copied by hand | In the design, once |
| When the design changes | The test still runs the old route | The next run takes the new route |
| How an element is found | A selector somebody guessed | The accessibility id the design carried into the code |
| An unreachable screen | Reported as a failing step | Reported as a design defect, before anything runs |
The suite that describes last quarter
Every team that has kept a UI test suite for more than a year knows the feeling. The tests pass, and they are testing a product that no longer quite exists. Somebody moved a step, somebody renamed a screen, and the suite was updated just enough to stay green.
The root cause is duplication. The journey exists twice: once in the design, and once in a test file that has to be kept in step by hand. Two copies of the same fact will diverge; that is not a discipline problem, it is arithmetic.
The flow is the test
A prototype in the Design surface is a graph: screens, and transitions carrying an event and an action. That is precisely the information a test case needs. Pathrule compiles that graph into a sequence of simulator actions and runs it against your app in a real simulator.
Because there is only one copy of the journey, there is nothing to keep in step. Rewire a transition and the next run takes the new route. Add a screen and it is covered. The suite cannot describe last quarter, because it is not a description at all; it is the design, executed.
Why node ids matter twice
Taps resolve by accessibility identifier or by label. That is the second reason the design's node ids travel into the code at handoff.
The first reason is comparison: with the id present, checking the built screen against the drawn one is exact rather than approximate. The second is this one: with the id present, an automated tap is unambiguous. One small piece of metadata, carried across the boundary, pays for itself in two different systems.
The rule that keeps the report worth opening
The flow is audited before it is executed. If the graph has a screen nothing reaches, or a transition whose trigger has no visible control, that is a design defect and it is reported as one, separately from what the app did.
This sounds like a detail and it is the difference between a report people read and a report people ignore. A run that blames the application for an authoring mistake trains you to distrust every red result, and once you distrust the suite you have paid for it and gained nothing.
The [UI tests documentation](/docs/design/ui-tests) covers the compilation and the audit, and the [simulator page](/docs/studio/simulator) covers the device side, including how you and an agent share control of one device.