Conclusion

In this lesson, you turned the reviewed feature plan’s user flow and acceptance criteria into a set of plain-English test steps, then had an AI agent execute those steps itself, directly against the running app through Xcode’s simulator MCP — taking each action and reading the screen afterward the same way a person would, rather than generating test code for something else to run. Finally, you saw the agent step outside the UI entirely: setting its own breakpoints, running the app, and reading the data printed to the console when execution stopped — debugging the app the same way you would from inside a live debug session.

The key takeaway is that plain-English test steps are instructions for the agent to carry out, not a specification for the code it writes. The agent reads the actions and expectations and performs them live against the running app — tapping, scrolling, reading the screen, setting breakpoints, reading the console — so the same written steps keep working as the app changes, without a separate test script to maintain. It’s also worth remembering that screenshot-driven simulator testing isn’t free: every screenshot is fresh, uncached tokens, so this approach is best spent on flows where seeing the real screen matters more than the cost of getting there. Breakpoint-and-console debugging is a cheaper alternative when what you need to verify is internal state rather than what’s rendered on screen — the agent doesn’t need a screenshot to know what a variable held, just the printed output from the debug session.

With that, you’ve carried this module’s tests from a consolidated, audit-driven unit test plan through to an agent that can execute UI test steps and debug the app directly against the running simulator — closing the loop on testing an AI-implemented feature end to end.