Introduction

The previous module left you with a feature that’s implemented, reviewed, and merged — but not tested. Along the way, you collected three separate audits:

• One audit checking the implementation against the plan’s goals, corner cases, and acceptance criteria.
• The next one from Xcode’s Dynamic Type specialist.
• Finally, you collected the third audit from Xcode’s VoiceOver specialist.

Each of those documents is useful on its own, but none of them is a test plan, and none of them tells you which findings are worth guarding with a unit test.

This lesson is not about how to write a unit test — the agent already knows how to do that. It’s about how to instruct the agent on which tests to write, and why. Handing an agent an open-ended “write unit tests” or “increase test coverage” prompt produces tests that pass but don’t protect anything you actually care about. A test suite is only as good as the reasoning that decided what belongs in it.

You’ll use Xcode to consolidate the three audits from the previous module into a single, defined list of proposed tests, each one tied back to a specific finding. That gives you, the human, a checkpoint: you can see every test the agent is about to write, the audit finding behind it, and decide to accept, reject, or adjust it before any test code exists. Only once that list is defined and approved does the agent move on to implementing the tests themselves.

By the end of this lesson you’ll be able to:

• Consolidate multiple AI-generated audits into a single, defined list of proposed unit tests.
• Tie each proposed test back to a specific audit finding, so its purpose is explicit before it’s written.
• Prompt an AI agent to write unit tests against that defined plan instead of an open-ended coverage goal.