Les tests de mutation sont négatifs. Les tests TDD sont positifs.

Retirer .trim() est une mutation d'appel de méthode classique. Elle survit dès qu'aucune fixture ne porte d'espaces autour, c'est-à-dire dans la plupart des cas — y compris les fixtures qu'un modèle a inventées pour son propre code.

// importer.js
const normalise = (value) => value.trim().toLowerCase();

export function importRows(rows) {
	return rows.map((row) => ({ email: normalise(row.email) }));
}

// Surviving mutant: normalise() with .trim() removed.
// The suite passes either way, so the report flags it.

Ce test tue le survivant. Il gèle aussi l'implémentation actuelle : normalise doit rester accessible et être appelée exactement ce nombre de fois. Renommez-la, inlinez-la ou déplacez-la derrière une frontière, et le test casse alors que le comportement n'a pas changé. Un agent qui optimise le score produit cette forme par défaut.

it('calls normalise once per row', () => {
	const spy = vi.spyOn(internals, 'normalise');
	importRows([{ email: ' Ada@Example.COM ' }]);
	expect(spy).toHaveBeenCalledTimes(1);
});

// Green. Mutant dead. Score up.
// Nothing here states what an imported email address should look like.

Même mutant, même mise à mort, mais l'assertion est une règle qu'un responsable produit pourrait lire. Elle passe par la fonction publique, donc les internes restent libres de bouger, et elle s'explique d'elle-même dans six mois au moment de l'échec.

it('trims and lower-cases every imported email address', () => {
	expect(importRows([{ email: ' Ada@Example.COM ' }]))
		.toEqual([{ email: 'ada@example.com' }]);
});

// Same mutant dead, but the suite gained a specification
// instead of a snapshot of today's call graph.

L'analyse de couverture par test est le plus grand levier de performance : elle n'exécute que les tests qui atteignent réellement chaque mutant. Le mode incrémental garde un run de pull request en quelques minutes. Le seuil break est un plancher contre la régression, pas une cible à poursuivre.

{
	"testRunner": "vitest",
	"coverageAnalysis": "perTest",
	"incremental": true,
	"mutate": ["src/**/*.js", "!src/**/*.test.js"],
	"thresholds": { "high": 80, "low": 60, "break": 60 }
}

Deux questions indépendantes, posées par une étape qui n'a pas écrit le code : ce code a-t-il une forme qui permet de le changer, et les tests qui le protègent réagissent-ils quand il change ? Les deux réponses vont sur la pull request, et aucune n'est négociable par l'auteur.

CHANGED=$(git diff --name-only origin/main... -- 'src/**/*.js')

# structural: complexity against coverage on touched methods
crap-report --changed-only --threshold 30 $CHANGED || exit 1

# behavioural: do the new tests notice anything?
stryker run --incremental --mutate "$CHANGED"

# survivors are review items with a named requirement attached,
# never a licence to write a test that pins the call graph.