Exercice 04 : Automatiser les tests sur chaque push

🎯 Objectifs

À la fin de cet exercice, vous serez capable de :

• ✅ Configurer un workflow qui lance npm test sur chaque push
• ✅ Utiliser continue-on-error: true pour ne pas bloquer le pipeline
• ✅ Forcer l'échec du pipeline quand les tests échouent (exit 1)
• ✅ Afficher un résumé des résultats dans les logs
• ✅ Interpréter les logs d'un pipeline en échec

Durée estimée : 20 min | Difficulté : ⭐⭐⭐☆☆

📖 Contexte

L'objectif principal d'un pipeline CI est de détecter les régressions automatiquement. Si un développeur pousse du code qui casse les tests, le pipeline doit :

1. Exécuter les tests sans exception
2. Signaler l'échec clairement (icône rouge, notification)
3. Bloquer toute fusion tant que le problème n'est pas corrigé

Il y a cependant des situations où vous voulez que les tests s'exécutent même s'ils échouent (pour collecter des métriques). C'est là qu'intervient continue-on-error.

📋 Énoncé

Vous allez créer une application Node.js avec une suite de tests Jest, puis configurer un pipeline qui les exécute automatiquement. Vous expérimenterez le comportement avec et sans continue-on-error.

🧭 Déroulement

Tâche 1 : Créer une application testable

Dans votre repository, créez calculator.js (une fonction add) et calculator.test.js (des tests Jest). Configurez package.json avec Jest comme runner de tests.

Indice :

`js

// calculator.js

function add(a, b) { return a + b; }

module.exports = { add };

`

`js

// calculator.test.js

const { add } = require('./calculator');

test('1 + 2 = 3', () => expect(add(1, 2)).toBe(3));

`

`json

// package.json

{ "scripts": { "test": "jest" }, "devDependencies": { "jest": "^29" } }

`

Vérification : npm install && npm test passe en local avec "1 passed".

Tâche 2 : Créer le workflow de tests

Créez .github/workflows/tests.yml. Le workflow doit se déclencher sur push et pull_request, cloner le code, configurer Node.js 20 avec cache npm, installer les dépendances et lancer les tests.

Indice :

`yaml

- name: Lancer les tests

run: npm test

`

Si npm test retourne un code de sortie non nul (tests en échec), le step échoue et le job est marqué en rouge par défaut.

Vérification : Après un push, l'onglet Actions montre un run vert si les tests passent, rouge s'ils échouent.

Tâche 3 : Observer le comportement par défaut

Introduisez intentionnellement un bug dans calculator.js (retournez a - b au lieu de a + b), poussez et observez le pipeline échouer.

Indice : Modifier calculator.js pour que add(1, 2) retourne −1. Le test expect(add(1, 2)).toBe(3) échouera.

Vérification : Le run GitHub Actions est rouge ❌. Les logs montrent "Expected: 3, Received: -1". Les steps suivants (s'il y en a) ne s'exécutent pas.

Tâche 4 : Utiliser continue-on-error

Corrigez le bug dans calculator.js. Ajoutez un second job rapport qui dépend du résultat du job test mais qui continue même si les tests échouent, en utilisant continue-on-error: true sur le step de tests.

Indice :

`yaml

- name: Lancer les tests

run: npm test

continue-on-error: true

`

Avec continue-on-error: true, le step est marqué en jaune (warning) si la commande échoue, mais le job continue. Utile pour collecter des résultats sans bloquer le pipeline.

Vérification : Réintroduisez le bug, poussez - le job continue malgré l'échec des tests. L'icône du step est jaune ⚠️, pas rouge ❌.

Tâche 5 : Forcer l'échec explicite du pipeline

Retirez continue-on-error et corrigez définitivement le bug. Ajoutez un step final qui affiche "✅ Tous les tests ont réussi" ou fait échouer le pipeline manuellement si une condition n'est pas remplie.

Indice :

`yaml

- name: Vérifier le succès

run: |

echo "✅ Tous les tests ont réussi"

echo "Commit : ${{ github.sha }}"

`

Pour forcer un échec conditionnel : exit 1 dans un run: fait immédiatement échouer le step et tout le job.

Vérification : Le pipeline final est entièrement vert avec le message de succès dans les logs.

🗂️ Mini-Projet

Ajoutez un rapport de couverture de code au pipeline. Jest peut générer un rapport de couverture avec --coverage.

# Checkpoints à valider :
# [ ] Le workflow se déclenche sur push et pull_request
# [ ] npm ci est utilisé pour l'installation
# [ ] npm test s'exécute et fait échouer le pipeline en cas d'erreur
# [ ] continue-on-error: true a été testé et compris
# [ ] Un step final affiche un message de succès
# [ ] Bonus : rapport de couverture uploadé comme artefact

Indice pour la couverture :

- name: Tests avec couverture
  run: npm test -- --coverage

- name: Uploader le rapport de couverture
  uses: actions/upload-artifact@v4
  with:
    name: coverage-report
    path: coverage/