Testing

When two services integrate, an implicit agreement is formed — a field name, a response shape, an error code. That agreement was never written as a test. Both services keep shipping. The agreement does not update. Contract testing makes the assumption explicit, verifiable, and enforced by CI before a breaking change reaches production.

AI can generate a complete test suite — descriptive names, 94% coverage, green CI — in the same session it writes the implementation. The gap is behavioral: tests written after code verify what the code does, not what it should. Mutation testing makes this visible.

When an AI agent works on your codebase, your test suite is the only artifact of intent it consistently sees. Tickets, Notion pages, and Slack threads do not enter the loop. If your tests describe what the system should do, the agent is constrained. If they only describe what the code already does, the agent ships whatever it generated.

Most teams have heard of mutation testing. The reason 90% of them never run it: nobody told them how. This is the operating manual — pick the tool, read the report, kill the surviving mutants, run it fast enough to gate every pull request.

Every team with a legacy codebase hits the same wall: you cannot add tests without refactoring, and you cannot refactor without tests. Characterisation tests are the specific tool — invented by Michael Feathers, amplified by AI — that breaks the loop.

Most teams treat TDD as a way to verify code works. That misses the point entirely. TDD is a design tool — Red-Green-Refactor shapes architecture before implementation, and the failing test is a specification, not a verification step.

Most test suites look healthy — high coverage, all green. But run mutation testing and you'll discover that 80-90% of tests would still pass even if you deleted the code they claim to test. Here's what decorative tests are, why they're dangerous, and how to fix them.