Testing | Blog

~/blog/tag/testing

Testing

The suite is the only thing standing between a confident agent and production. What it has to be worth for that to hold.

What I write about here

Generation got cheap, so the test suite quietly changed job. It used to be a safety net under code somebody had already reasoned about. Now it is often the only thing that reasoned about the code at all.

That puts weight on tests they were never designed to carry, and it exposes how little most suites actually assert. A passing suite tells you the code ran. Coverage tells you a line was executed. Neither tells you anything would fail if the behaviour changed, which is the only question that matters when the author was a model that will happily write a test asserting what the code already does.

Mutation testing is the instrument that answers it, and it is the one I keep coming back to here. Break something on purpose, see whether the suite notices. The number that comes out is usually lower than people expect and always more useful than coverage.

The other posts under this tag deal with the surrounding problems. Characterization tests, because pinning existing behaviour is the precondition for letting an agent touch legacy code rather than a nice-to-have. Baselines that grandfather what already exists and refuse what was just added. Frozen task sets, for when the question is whether a model change made your output worse and re-running the prompt cannot tell you.

The argument for why any of this matters is in the AI and code quality guide. The code-quality series puts the method posts in reading order.

latest
crafttoolingtesting
8 mincode-quality #6

Quality ratchets for AI code: baselines that only tighten

A lint baseline lets you enforce a standard you cannot fix today. Existing violations are grandfathered, new ones fail the build, and the file can only shrink. How PHPStan, ESLint, detekt and Sonar do it, and the four ways a ratchet quietly stops working.

read →