tests automatisés : déclenchement et rapports

Objectifs

Configurer un workflow GitHub Actions pour lancer automatiquement votre suite de tests.
Comprendre comment un test qui échoue fait échouer tout le pipeline.
Générer un rapport de test structuré (par exemple, au format JUnit XML).
Uploader ce rapport comme un “artefact” pour pouvoir l’analyser après l’exécution.

L’étape de test dans le pipeline

L’étape de test est le cœur de l’Intégration Continue. C’est elle qui valide que les nouveaux changements n’ont pas introduit de régression.

Dans un workflow GitHub Actions, il s’agit simplement d’une step qui exécute la commande de test de votre projet.

# Extrait d'un fichier de workflow
# ... (après les étapes de checkout et d'installation)
- name: Lancer les tests
  run: pytest # ou 'npm test', 'go test', etc.

Comportement en cas d’échec

Si la commande de test se termine avec un code de sortie non-nul (ce qui arrive quand un test échoue), GitHub Actions considère que l’étape a échoué. Par défaut, cela provoque l’échec du job entier et, par conséquent, de tout le workflow. Une croix rouge apparaîtra à côté de votre commit, signalant clairement que le code est cassé.

Générer et sauvegarder des rapports de test

Lorsque des tests échouent dans un pipeline distant, il est essentiel d’avoir des logs détaillés pour comprendre pourquoi, sans avoir à relancer les tests sur sa propre machine. C’est le rôle des rapports de test.

1. Générer un rapport

La plupart des frameworks de test peuvent générer des rapports dans un format standard comme JUnit XML.

Avec pytest (Python) :
```
pytest --junitxml=report.xml
```

2. Uploader le rapport comme un artefact

Un artefact est un fichier produit par un job (un binaire, un document, un rapport…). GitHub Actions vous permet de stocker ces artefacts pour les télécharger plus tard. On utilise l’action actions/upload-artifact.

C’est particulièrement utile pour ne sauvegarder les rapports que lorsque les tests échouent.

Exemple de workflow complet

Ce workflow exécute des tests pytest, génère un rapport XML, et n’uploade ce rapport que si l’étape de test a échoué.

name: CI avec Tests et Rapports

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Installer Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'
          cache: 'pip' # Active le cache pour les dépendances

      - name: Installer les dépendances
        run: pip install -r requirements.txt

      - name: Lancer les tests et générer un rapport
        # 'continue-on-error: true' permet au workflow de continuer même si cette étape échoue,
        # afin que l'étape suivante (upload) puisse s'exécuter.
        id: tests
        run: pytest --junitxml=report.xml
        continue-on-error: true

      - name: Uploader le rapport de tests (si échec)
        # On utilise l'output de l'étape 'tests' pour conditionner cette étape.
        # 'steps.tests.outcome' sera 'failure' si les tests ont échoué.
        if: steps.tests.outcome == 'failure'
        uses: actions/upload-artifact@v4
        with:
          name: rapport-de-tests
          path: report.xml
      
      - name: Vérifier le statut des tests (pour faire échouer le job)
        # Cette dernière étape sert à faire échouer le job si les tests ont échoué.
        if: steps.tests.outcome == 'failure'
        run: exit 1

Bonnes pratiques

Testez sur chaque push et pull_request. Cela garantit qu’aucun code non testé n’arrive sur votre branche principale.
Utilisez le cache pour les dépendances. Cela peut considérablement accélérer votre pipeline en évitant de retélécharger les paquets à chaque fois.
Séparez les tests rapides et lents. Si vous avez des tests d’intégration qui durent longtemps, exécutez-les dans un job séparé, potentiellement moins souvent (par exemple, uniquement la nuit).

Pièges courants

“Flaky tests” : Des tests qui échouent de manière aléatoire sans raison apparente. Ils détruisent la confiance dans le pipeline et doivent être corrigés ou supprimés sans pitié.
Ne pas sauvegarder les rapports d’échec : Cela oblige les développeurs à essayer de reproduire l’erreur en local, ce qui est une perte de temps.

Exercices

Ajoutez une étape de test à votre workflow :
- Reprenez le workflow hello.yml de la leçon précédente.
- Ajoutez une step nommée “Lancer un test simple”.
- Pour la commande run, utilisez exit 1 pour simuler un test qui échoue.
- Poussez le changement et observez que votre workflow est maintenant rouge.
Créez et uploadez un artefact :
- Dans une nouvelle branche, créez un fichier rapport_test.txt.
- Ajoutez une étape à votre workflow qui utilise actions/upload-artifact pour uploader ce fichier.
- Créez une Pull Request avec votre changement.
- Une fois le workflow terminé, allez sur la page de l’exécution et vérifiez que vous pouvez télécharger l’artefact “rapport_test”.

Menu