Post

Frequently work with teams who are uncomfortable changing software they own because of low test confidence and / or coverage. Generated this small tool for .NET projects (it's written in TypeScript, don't loose your minds) which acts as a meta-harness, instruments a codebase with Coverlet + Stryker

It has canned prompts that do their best to mimic your existing test style and only isolate out of process dependencies, with a deterministic shell that measures coverage and mutation test rules, letting the agents only do the test uplift, rather than an agent judging the work.

These tests, while stylistically "component tests" probably act more like snapshot testing - the idea is that they lock in what the program currently does, using the big statistical dice roll machine to do the thing it's good at (fuzzy matching and replication).

There's a strong focus on purely outside-in tests, rather than unit testing, because anything more granular would lock you into your specific implementation and make your code harder to change.

0 reposts0 likes

YMMV, paint dripping so wet my hands are covered in it currently, but I've just done a few runs on some real world apps in a couple of hours that dragged coverage and confidence (resilience to mutation) up from ~60% to 98% in an hour of spinning.

It's interesting to use something that I use primarily for human feedback (a TDD style workflow) and take it's *artefact* as a tool for automation. These are not "tests" as I previously understood them, but I'll experiment with any tool to get to strong foundations.