Tests automatisés dans la CI et protection de branche

Les tests automatisés dans la CI sont les tests unitaires, d'intégration et de bout en bout que le pipeline exécute à chaque modification, sans intervention humaine ; leur échec rend le pipeline rouge. Associés à une règle de protection de branche, ils deviennent une barrière : une pull request dont les tests échouent ne peut pas être fusionnée. Ce chapitre montre comment préparer un projet pour la CI, tester contre une vraie base de données, publier les résultats, fixer un seuil de couverture, traiter les tests instables et configurer la protection de la branche main.

Quels tests, dans quel pipeline

Tous les tests n'ont pas le même coût. On les range en pyramide : beaucoup de tests unitaires rapides à la base, moins de tests d'intégration, très peu de tests de bout en bout au sommet (les types de tests et la pyramide).

Préparer le projet : des scripts standards

Le pipeline doit appeler des commandes simples, les mêmes qu'en local. On les déclare dans package.json :

{
  "scripts": {
    "lint": "eslint . --max-warnings 0",
    "format:check": "prettier --check .",
    "test": "jest",
    "test:integration": "jest --config jest.integration.config.js --runInBand",
    "build": "node scripts/build.js"
  }
}

• --max-warnings 0 fait échouer ESLint au moindre avertissement : sinon, les avertissements s'accumulent et plus personne ne les lit.
• --runInBand exécute les tests d'intégration un par un, dans le même processus : ils partagent une base de données et ne doivent pas se marcher dessus.
• La CI appelle npm run lint, npm test, npm run test:integration. Si l'équipe change d'outil de test, le workflow ne change pas.

Les autres écosystèmes suivent la même logique : un Makefile ou des scripts Composer (composer test) pour PHP, dotnet test pour C#, pytest pour Python.

Tester avec une vraie base de données

Les tests d'intégration de sorbier-frais ont besoin d'une base MySQL. Sur GitHub Actions, la clé services démarre un conteneur à côté du job, le temps du job :

jobs:
  tests-integration:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    services:
      mysql:
        image: mysql:8.4
        env:
          MYSQL_ROOT_PASSWORD: root
          MYSQL_DATABASE: frais_test
        ports:
          - 3306:3306
        options: >-
          --health-cmd="mysqladmin ping -h 127.0.0.1 -proot"
          --health-interval=5s
          --health-timeout=3s
          --health-retries=10
    env:
      DB_HOST: 127.0.0.1
      DB_PORT: 3306
      DB_USER: root
      DB_PASSWORD: root
      DB_NAME: frais_test
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - name: Créer les tables
        run: mysql -h 127.0.0.1 -uroot -proot frais_test < sql/schema.sql
      - name: Lancer les tests d'intégration
        run: npm run test:integration

Le mot de passe root n'est pas un secret : la base est vide, créée pour le job, détruite à la fin et inaccessible de l'extérieur. Les données de production ne vont jamais dans une base de test : on utilise un jeu de données fictif versionné (les jeux de données de test).

Publier les résultats des tests

Un journal de 2 000 lignes n'est pas le meilleur moyen de savoir quel test a échoué. Deux formats standards permettent aux outils d'afficher les résultats :

• JUnit XML pour le résultat des tests : nom, durée, réussite ou échec, message d'erreur. Presque tous les outils savent le produire et le lire.
• Cobertura ou LCOV pour la couverture du code.

Avec Jest, on ajoute le paquet jest-junit (npm install --save-dev jest-junit) et on configure jest.config.js :

module.exports = {
  testEnvironment: 'node',
  reporters: ['default', ['jest-junit', { outputDirectory: 'reports', outputName: 'junit.xml' }]],
  collectCoverageFrom: ['src/**/*.js'],
  coverageReporters: ['text', 'lcov', 'cobertura', 'json-summary'],
  coverageThreshold: {
    global: { lines: 80, branches: 70 },
  },
};

Dans GitHub Actions, on conserve les rapports comme artefacts, même en cas d'échec, et on écrit un résumé lisible sur la page de l'exécution :

      - name: Tests avec couverture
        run: npm test -- --ci --coverage
      - name: Conserver les rapports
        if: always()
        uses: actions/upload-artifact@v7
        with:
          name: rapports-tests
          path: |
            reports/
            coverage/
          retention-days: 14
      - name: Résumé de la couverture
        if: always()
        run: |
          echo '### Couverture des tests' >> "$GITHUB_STEP_SUMMARY"
          node -e "const t = require('./coverage/coverage-summary.json').total; console.log('Lignes ' + t.lines.pct + ' %, branches ' + t.branches.pct + ' %')" >> "$GITHUB_STEP_SUMMARY" || true

Le rapporteur json-summary écrit les totaux dans coverage/coverage-summary.json ; une ligne de Node.js les ajoute au résumé. Le || true est assumé : si les tests ont planté avant de produire le fichier, le résumé est un confort, il ne doit pas ajouter une seconde erreur à la première. GitLab, lui, lit directement le JUnit XML et la couverture Cobertura et les affiche dans la merge request (artefacts et rapports dans GitLab).

La couverture de code et son seuil

La couverture de code est la part du code exécutée au moins une fois par les tests : lignes, branches (chaque côté d'un if), fonctions. Un seuil dans la configuration fait échouer les tests quand la couverture descend en dessous :

Jest: "global" coverage threshold for lines (80%) not met: 76.47%

Le seuil empêche qu'une fonctionnalité entière arrive sans test. Mais une couverture élevée ne prouve pas que les tests sont bons : un test qui appelle une fonction sans rien vérifier (sans expect) augmente la couverture sans rien tester. Fixe un seuil réaliste (70 à 80 % des lignes pour une API), monte-le progressivement, et regarde surtout les branches non couvertes du code que tu viens de modifier. Le chapitre Couverture de code et tests de mutation du cours Tests montre comment mesurer si les tests vérifient vraiment quelque chose.

La qualité du code : lint et quality gate

Le lint et le formatage sont les vérifications de qualité les plus simples (vérifications statiques). Les équipes plus grandes ajoutent une plateforme d'analyse comme SonarQube (installé dans l'entreprise) ou SonarQube Cloud (gratuit pour les projets publics). À chaque analyse, elle mesure la couverture, les duplications, la complexité, les erreurs probables et les failles connues, puis applique une porte qualité (quality gate) : un ensemble de conditions, par exemple « pas de nouveau bug, couverture du nouveau code d'au moins 80 %, moins de 3 % de lignes dupliquées ». Si la porte est fermée, le contrôle est rouge et la pull request bloquée.

La porte qualité porte sur le nouveau code : on n'exige pas de reprendre tout l'historique, mais on interdit d'ajouter de la dette technique. C'est un bon argument pour l'indicateur « Évaluer la qualité d'une solution applicative » de l'E6 SLAM.

Les tests instables

Un test instable (flaky test) réussit ou échoue au hasard, sans que le code change. C'est le pire ennemi d'une CI : après trois fausses alertes, l'équipe relance sans lire, puis fusionne malgré le rouge.

La relance automatique des tests en échec (jest.retryTimes(2)) masque le problème sans le résoudre. Quand un test est instable, on le corrige tout de suite ; si c'est impossible, on le met en quarantaine (désactivé, avec un ticket et un responsable), plutôt que de laisser toute l'équipe s'habituer au rouge.

Faire de la CI une barrière : la protection de branche

Un pipeline rouge que l'on peut ignorer ne protège rien. Sur GitHub, une règle de protection de branche ou un ruleset rend les contrôles obligatoires. Dans Settings, Rules, Rulesets, New branch ruleset, cible la branche main et active (protéger la branche main) :

Les rulesets sont la forme récente des règles de protection : plusieurs règles peuvent s'appliquer à la même branche, on peut les activer en mode Evaluate pour observer avant d'imposer, et une liste de contournement (bypass list) précise qui peut passer outre. Laisse cette liste vide sur un projet d'équipe : la règle vaut aussi pour les administrateurs.

Disponibilité. Les règles de protection et les rulesets sont disponibles pour les dépôts publics avec l'offre gratuite, et pour les dépôts privés avec les offres payantes, dont GitHub Pro, offert aux étudiants par le GitHub Student Developer Pack.

Désigner les relecteurs : CODEOWNERS. Le fichier .github/CODEOWNERS associe des chemins à des responsables, automatiquement demandés en revue ; avec le réglage Require review from Code Owners, leur approbation devient obligatoire :

# Fichier .github/CODEOWNERS
*                    @lina-sorbier @hugo-sorbier
/.github/workflows/  @lina-sorbier
/sql/                @hugo-sorbier

La ligne sur .github/workflows/ est une protection importante : modifier un workflow, c'est modifier ce qui s'exécute avec les secrets du dépôt.

Sur GitLab, l'équivalent se règle en deux endroits : Settings, Repository, Protected branches (qui peut pousser et fusionner sur main), et Settings, Merge requests, case Pipelines must succeed (une merge request ne peut être fusionnée que si son pipeline réussit).

Exercices

FAIL tests/indemnites.test.js
  ● calculerIndemnite › applique 0,25 € par km au-delà de 5 000 km

    expect(received).toBe(expected) // Object.is equality

    Expected: 2250
    Received: 2400

      14 |   test('applique 0,25 € par km au-delà de 5 000 km', () => {
    > 15 |     expect(calculerIndemnite(6000)).toBe(2250);
         |                                     ^
      16 |   });

Tests:       1 failed, 41 passed, 42 total
Error: Process completed with exit code 1.

  tests-ok:
    needs: tests
    if: always()
    runs-on: ubuntu-latest
    steps:
      - run: test "${{ needs.tests.result }}" = "success"

test('une note créée apparaît dans la liste', async () => {
  creerNote({ montant: 42.5, motif: 'Taxi' });   // insère la note en base, renvoie une promesse
  const notes = await listerNotes();               // lit toutes les notes
  expect(notes).toHaveLength(1);
});

test('une note créée apparaît dans la liste', async () => {
  await creerNote({ montant: 42.5, motif: 'Taxi' });
  const notes = await listerNotes();
  expect(notes).toHaveLength(1);
});