Couverture de code, tests de mutation et tests dans la CI

La couverture de code (code coverage) est la part du code source exécutée au moins une fois par les tests, mesurée en lignes, en instructions, en branches et en fonctions. Elle montre ce qu'aucun test ne touche, mais elle ne dit pas si les tests vérifient quelque chose : une couverture de 100 % peut cacher des tests faibles. Les tests de mutation mesurent justement la qualité des tests. Ce chapitre mesure la couverture de Prêt'Matos avec Vitest, xUnit et PHPUnit, en montre les limites avec un outil de mutation, puis fait tourner les tests à chaque push dans la CI.

Mesurer la couverture avec Vitest

Vitest mesure la couverture avec le moteur intégré à Node.js (V8). Le paquet s'installe une fois :

npm install --save-dev @vitest/coverage-v8
npx vitest run --coverage

 % Coverage report from v8
------------------|---------|----------|---------|---------|-------------------
File              | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
------------------|---------|----------|---------|---------|-------------------
All files         |   90.52 |     85.1 |   83.33 |   91.76 |
 app.js           |   94.11 |    81.48 |    87.5 |   96.87 | 26
 depot-memoire.js |      95 |    71.42 |    92.3 |    92.3 | 8
 depot-mysql.js   |       0 |      100 |       0 |       0 | 3-18
 jeu-de-test.js   |     100 |      100 |     100 |     100 |
 rappels.js       |     100 |      100 |     100 |     100 |
 regles.js        |     100 |      100 |     100 |     100 |
------------------|---------|----------|---------|---------|-------------------

Le rapport s'écrit aussi en HTML dans coverage/index.html : ouvre-le dans un navigateur, clique sur un fichier, et chaque ligne apparaît en vert (exécutée), en rouge (jamais exécutée) ou en jaune (une branche d'une condition n'a jamais été prise). C'est la vue la plus utile pour trouver les trous.

Les quatre mesures

Que nous apprend ce rapport ?

• app.js, ligne 26 : c'est le corps de la route GET /api/materiels. Aucun test d'intégration ne l'appelle. Le trou est réel : une route sans test.
• depot-memoire.js, ligne 8 : listerMateriels, pour la même raison.
• depot-mysql.js, 0 % : ses tests sont sautés quand aucune base MySQL n'est configurée (chapitre 8). Dans la CI, avec la base, ils tourneront. Le rapport local ne doit pas faire paniquer, mais il rappelle que ce fichier n'est testé que là.
• regles.js, 100 % partout. Cela veut-il dire que ses tests sont parfaits ? La suite du chapitre montre que non.

La couverture en C# et en PHP

Pour Prêt'Matos en C#, la commande donne une couverture de 100 % des lignes et des branches de PretMatos.Domaine (53 lignes, 14 branches). Sans extension de couverture installée, PHPUnit affiche un avertissement et ne mesure rien : c'est une erreur fréquente le jour où l'on veut une capture pour le dossier E6.

Ce que la couverture ne dit pas

Voici une autre suite de tests pour regles.js, écrite trop vite :

// Des tests qui exécutent toutes les lignes de verifierReservation… sans tester les limites.
test('accepte', () => {
  expect(verifierReservation({ materiel: 'PC-07', debut: '2027-03-20', fin: '2027-03-22' }, existantes, '2027-03-08').acceptee).toBe(true);
});
test('fin avant début', () => {
  expect(verifierReservation({ materiel: 'PC-07', debut: '2027-03-20', fin: '2027-03-01' }, existantes, '2027-03-08').acceptee).toBe(false);
});
test('passé', () => {
  expect(verifierReservation({ materiel: 'PC-07', debut: '2027-03-01', fin: '2027-03-02' }, existantes, '2027-03-08').acceptee).toBe(false);
});
test('trop long', () => {
  expect(verifierReservation({ materiel: 'PC-07', debut: '2027-03-20', fin: '2027-04-30' }, existantes, '2027-03-08').acceptee).toBe(false);
});
test('conflit', () => {
  expect(verifierReservation({ materiel: 'PC-07', debut: '2027-03-11', fin: '2027-03-12' }, existantes, '2027-03-08').acceptee).toBe(false);
});

Avec un dernier test qui appelle une fois chacune des autres fonctions, cette suite atteint 100 % en instructions, branches, fonctions et lignes sur regles.js. Pourtant :

• elle ne teste aucune valeur limite : un prêt de 42 jours est refusé, mais rien ne vérifie que 15 jours passent et que 16 non. Remplacer > DUREE_MAX_JOURS par >= DUREE_MAX_JOURS (refuser les prêts de 15 jours) ne ferait échouer aucun test ;
• elle ne vérifie aucun motif : un message vide passerait.

La couverture dit qu'une ligne a été exécutée, pas qu'un test vérifie son résultat. C'est sa limite fondamentale, et c'est pourquoi viser 100 % de couverture comme un objectif en soi conduit à écrire des tests creux.

Mesurer la qualité des tests avec les tests de mutation

Un test de mutation introduit volontairement de petits défauts dans le code, un à la fois, et relance les tests pour chacun. Chaque version modifiée s'appelle un mutant : un > changé en >=, un true en false, une chaîne vidée, une condition remplacée par true. Si un test échoue, le mutant est tué : les tests ont vu le défaut. Si tous les tests passent, le mutant survit : les tests n'ont pas vu la différence. Le score de mutation est la part des mutants tués.

En JavaScript, l'outil de référence est Stryker, qui sait piloter Vitest :

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

{
  "testRunner": "vitest",
  "mutate": ["src/regles.js"],
  "reporters": ["clear-text", "html", "progress"]
}

Ce fichier stryker.config.json dit quoi muter ; npx stryker run lance l'analyse. Sur la suite faible ci-dessus, couverte à 100 %, le verdict tombe :

File       |  total | covered | # killed | # timeout | # survived | # no cov | # errors |
-----------|--------|---------|----------|-----------|------------|----------|----------|
 regles.js |  81.54 |   81.54 |       53 |         0 |         12 |        0 |        0 |

Douze mutants survivent sur 65. Parmi eux, celui-ci :

[Survived] EqualityOperator
src/regles.js:35:7
-     if (dureeEnJours(demande.debut, demande.fin) > DUREE_MAX_JOURS) {
+     if (dureeEnJours(demande.debut, demande.fin) >= DUREE_MAX_JOURS) {

Exactement le défaut annoncé : refuser les prêts de 15 jours ne fait échouer aucun test.

Et la suite soignée du chapitre 4, avec ses valeurs limites ? Elle fait mieux, sans être parfaite : 92,31 %, 60 mutants tués, 5 survivants. Les survivants sont instructifs :

[Survived] EqualityOperator
src/regles.js:25:58
-     return numeroDeJour(a.debut) <= numeroDeJour(b.fin) && numeroDeJour(b.debut) <= numeroDeJour(a.fin);
+     return numeroDeJour(a.debut) <= numeroDeJour(b.fin) && numeroDeJour(b.debut) < numeroDeJour(a.fin);

[Survived] EqualityOperator
src/regles.js:29:7
-     if (numeroDeJour(demande.fin) < numeroDeJour(demande.debut)) {
+     if (numeroDeJour(demande.fin) <= numeroDeJour(demande.debut)) {

[Survived] BooleanLiteral
src/regles.js:30:24
-       return { acceptee: false, motif: 'La date de fin précède la date de début.' };
+       return { acceptee: true, motif: 'La date de fin précède la date de début.' };

(et deux autres mutants du même type que le dernier, sur les motifs « début passé » et « 16 jours »).

Avec ces trois compléments, Stryker annonce 100 % : les 65 mutants sont tués. Le test de mutation a trouvé, automatiquement, le cas limite qu'un humain avait oublié, et celui-là même qui avait causé un incident en production.

Fixer un seuil raisonnable

Un seuil de couverture fait échouer la commande de test si la couverture descend en dessous d'une valeur. Avec Vitest :

// vitest.config.js
import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    coverage: {
      provider: 'v8',
      include: ['src/**/*.js'],
      exclude: ['src/server.js', 'src/serveur-recette.js'],
      thresholds: {
        lines: 80,
        branches: 75,
      },
    },
  },
});

Si un seuil n'est pas atteint, Vitest affiche un message de ce type et la commande échoue :

ERROR: Coverage for branches (72.4%) does not meet global threshold (75%)

Lancer les tests dans la CI

L'intégration continue (CI) rejoue automatiquement les tests à chaque push et à chaque pull request, dans un environnement propre. C'est elle qui transforme ta suite de tests en filet de sécurité pour toute l'équipe : avec une règle de protection de branche, une pull request dont les tests échouent ne peut pas être fusionnée. Le cours Intégration continue détaille tout cela ; voici un workflow GitHub Actions minimal pour Prêt'Matos :

# .github/workflows/tests.yml
name: Tests

on:
  push:
    branches: [main]
  pull_request:

jobs:
  tests-js:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm run test:couverture
      - name: Conserver le rapport de couverture
        if: always()
        uses: actions/upload-artifact@v7
        with:
          name: couverture
          path: coverage/

  tests-e2e:
    runs-on: ubuntu-latest
    needs: tests-js
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npx vite build
      - run: npx playwright test
      - name: Conserver le rapport Playwright
        if: failure()
        uses: actions/upload-artifact@v7
        with:
          name: rapport-playwright
          path: playwright-report/

  tests-csharp:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-dotnet@v6
        with:
          dotnet-version: 10.0.x
      - run: dotnet test --collect:"XPlat Code Coverage"

La variable d'environnement CI vaut true sur les runners de GitHub : la configuration Playwright du chapitre 9 active alors les relances et refuse de réutiliser un serveur existant. Pour brancher la base MySQL de test, publier les résultats des tests dans la pull request et protéger la branche main, suis le chapitre Tests automatisés dans la CI du cours Intégration continue. Pour GitLab, le principe est identique dans un fichier .gitlab-ci.yml (GitLab CI).

Exercices

export function estEnRetard(pret, aujourdhui) {
  if (pret.rendu) return false;
  return aujourdhui >= pret.fin;
}

test("un prêt rendu n'est jamais en retard", () => {
  expect(estEnRetard({ fin: '2027-03-14', rendu: true }, '2027-03-20')).toBe(false);
});

test('un prêt non rendu après sa date de fin est en retard', () => {
  expect(estEnRetard({ fin: '2027-03-14', rendu: false }, '2027-03-20')).toBe(true);
});

test("un prêt n'est pas en retard le jour de sa date de fin", () => {
  expect(estEnRetard({ fin: '2027-03-14', rendu: false }, '2027-03-14')).toBe(false);
});

[Survived] ArithmeticOperator
-   date.setUTCDate(date.getUTCDate() + 1);
+   date.setUTCDate(date.getUTCDate() - 1);

test('le lendemain du 13 mars est le 14 mars', () => {
  expect(lendemain('2027-03-13')).toBe('2027-03-14');
});

name: Tests
on: [push]
jobs:
  tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-node@v7
        with:
          node-version: 24
      - run: npm install
      - run: npm test || true

    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm test