6.2.2. Edge Cases and Assertions
💡 First Principle: The hardest part of testing is imagining what could go wrong; Copilot helps brainstorm edge cases and write assertions, but the developer must steer it toward the boundaries that matter for their specific logic.
Beyond happy-path tests, Copilot can help identify edge cases (empty inputs, nulls, boundary values, error conditions) and write the assertions that check them. Prompted well — "add tests for empty input, maximum size, and invalid characters" — it produces targeted cases. This directly addresses the most common testing weakness: missing the unusual inputs.
A scenario: a date-parsing function works on valid dates. The developer asks Copilot to add edge cases — leap years, invalid formats, timezone boundaries — and gets assertions for each, catching bugs the happy path hid.
💡 Key Point: Copilot is a good edge-case brainstorming partner. You still decide which edges matter for your domain and confirm the assertions are correct.
⚠️ Exam Trap: Copilot won't automatically know every edge case relevant to your business logic. Directing it ("test these specific conditions") is the developer's job; assuming it covers all edges unprompted is the mistake.
Reflection Question: How can Copilot help with edge cases, and why does the developer still need to direct which boundaries get tested?
