Tests de mutation en TypeScript : casser le code pour l'améliorer

Êtes-vous sûr que vos tests fonctionnent vraiment ?

Imaginez : vous avez 95% de couverture de code, tous les tests sont verts, le CI/CD passe sans erreur. L'équipe est satisfaite, le manager est serein. Mais un jour, un bug apparaît en production. Vous ouvrez le code, regardez les tests et comprenez : ils vérifient simplement que la fonction retourne un nombre, sans regarder sa valeur. Ou pire — le test est écrit de telle manière qu'il réussit dans tous les cas.

Une situation familière ? Bienvenue dans le monde où le pourcentage de couverture n'est qu'un chiffre, pas une garantie de qualité. C'est là qu'intervient le test de mutation (mutation testing) — une méthode qui fait vraiment souffrir vos tests et les oblige à prouver leur valeur.

Dans cet article, nous verrons comment intégrer le mutation testing dans un projet TypeScript en utilisant Stryker, et pourquoi cela pourrait devenir votre nouvel outil préféré (ou une nouvelle source de maux de tête).

Qu'est-ce que le test de mutation en termes simples ?

Le test de mutation, c'est quand vous prenez votre code, y introduisez délibérément de petites erreurs (mutations) et regardez si vos tests échouent. Si les tests ne tombent pas — vous testez mal. S'ils tombent — bravo, le mutant est éliminé.

Ça semble sadique ? Peut-être. Mais ça marche. Imaginez que vous êtes un ingénieur QA qui s'est furtivement glissé dans le code et a remplacé === par ==, > par < ou a supprimé un appel de fonction. Un bon test doit le détecter. Un mauvais test le laissera passer.

En TypeScript, avec son typage strict, le test de mutation est particulièrement utile : il détecte les cas où les types sont corrects, mais la logique ne l'est pas.

Pourquoi la couverture de code classique (code coverage) est une illusion ?

Supposons que vous ayez une fonction :

function calculateDiscount(price: number, isPremium: boolean): number {\n  if (isPremium) {\n    return price * 0.8;\n  }\n  return price;\n}

Et un test :

test('returns number', () => {\n  const result = calculateDiscount(100, true);\n  expect(typeof result).toBe('number');\n});

Couverture ? 100%. Test ? Réussi. Et si on remplace price * 0.8 par price * 0.5 ? Le test réussira quand même — il ne vérifie que le type, pas la valeur. Voilà un faux sentiment de sécurité.

Le test de mutation mettra en évidence une telle mutation et dira : « Hé, ton test n'a pas remarqué que j'ai changé la réduction ! ». Et vous devrez ajouter une vérification correcte.

Comment fonctionne le mutation testing en TypeScript : étape par étape

L'ensemble du processus peut être divisé en trois étapes :

\n
1. Génération de mutants — l'outil copie votre code et apporte une modification à la fois. Par exemple, il change && en || ou supprime un appel de méthode.
\n
2. Exécution des tests — pour chaque mutant, vos tests sont lancés.
\n
3. Analyse des résultats — si les tests échouent, le mutant est « tué ». Sinon, il a « survécu », et c'est une zone de risque.
\n

La métrique principale est le mutation score (pourcentage de mutants tués). 100% est l'idéal, mais en pratique, 80-90% est déjà excellent.

L'outil n°1 pour TypeScript : Stryker

Dans le monde de TypeScript et JavaScript, le roi du test de mutation est Stryker (StrykerJS). Il est rapide, fonctionne avec Jest, Vitest, Mocha et même avec les tests navigateur. Configuration en 5 minutes.

Installation :

npm install --save-dev @stryker-mutator/core @stryker-mutator/jest-runner

Créons le fichier de configuration stryker.conf.js :

// stryker.conf.js\nexport default {\n  mutate: ['src/**/*.ts', '!src/**/*.spec.ts'], // quoi muter\n  testRunner: 'jest',\n  reporters: ['html', 'clear-text', 'progress'],\n  jest: {\n    projectType: 'custom',\n    configFile: 'jest.config.ts',\n  },\n  concurrency: 4, // combien de mutants