Write examples before generating tests
For a discount input, decide how zero, one hundred percent, negative values, values above the limit and missing input should behave. Confirm concrete inputs and outputs independently, including rounding where relevant. Supplying those examples prevents current implementation behavior from becoming the unquestioned test oracle.
Choose distinct cases, not a large count
Ten similar successful values can miss one important boundary. Organize cases by valid behavior, boundaries, invalid input and exceptions, then remove redundant checks. Name the behavior being protected so a later failure indicates what changed, rather than merely reporting which arbitrary fixture stopped matching.
Avoid mirroring implementation details
Tests tied only to internal names or incidental call counts can break during harmless refactoring. Prefer observable outputs and required effects; justify checks of internal structure when they matter. When an agent changes implementation and tests together, recheck the original independently agreed examples instead of accepting a green result alone.
Demonstrate that the test detects the defect
A regression test is stronger when it fails on the original defect and passes after the fix. You can also deliberately change one protected behavior and verify that the test detects it. If meaningful changes never cause a failure, inspect whether the test validates only setup rather than the intended behavior.
Example: specifying a discount calculation
For a fictional rule, specify that applying a ten-percent discount to 1,000 units produces 900. Then define zero, full discount and invalid-input behavior. These are test-specification examples, not product prices. Ask for tests of the agreed rules and inspect whether the generated suite silently invents rounding or validation requirements that the specification never established.
Leave a useful verification record
With tools such as Claude Code, Cline or Aider, retain the command, test scope, result and unverified conditions. A mocked external API does not establish a working live integration. Describe the behavior now protected in the review, rather than treating the number of new tests as the outcome.
Official sources
Pricing, availability and feature limits can change. Check the linked official pages before subscribing.
- Claude Code overviewInformation checked: 2026-10-27
- Cline overviewInformation checked: 2026-10-27
- Aider usageInformation checked: 2026-10-27
- Claude Code costsInformation checked: 2026-10-27
- Claude Code permissionsInformation checked: 2026-10-27
- Cline authorization and model accessInformation checked: 2026-10-27
- Cline local modelsInformation checked: 2026-10-27
- Aider chat modesInformation checked: 2026-10-27
- Aider models and keysInformation checked: 2026-10-27