6.2.1. Generating Unit and Integration Tests
💡 First Principle: Copilot turns "I should write tests" into "here are tests to review," removing the blank-page friction that causes testing to be skipped. The generated tests are a starting scaffold, not a finished safety net.
Copilot can generate unit tests for a function and integration tests across components, often inferring reasonable cases from the code's structure. Slash commands like /tests make this a one-step request in Chat. This is genuinely valuable: it gets a test suite started quickly, especially for code that was written without tests.
A scenario: a developer has an untested utility module. Using /tests, Copilot scaffolds a suite covering the obvious cases in minutes. The developer then reviews it, adds the cases Copilot missed, and confirms the assertions actually check the right things.
✅ Best Practice: Treat generated tests as a first draft of coverage. Read each test — confirm it asserts meaningful behavior and isn't just exercising code without checking outcomes.
⚠️ Exam Trap: "Copilot wrote the tests, so we have coverage" is the trap. Generated tests can be shallow or miss edges; coverage is something you verify, not something generation guarantees.
Reflection Question: Why is a generated test suite a starting point rather than proof of coverage, and what does the developer add to make it trustworthy?
