Tests automatisés dans un pipeline CI/CD : GitHub Actions, GitLab CI, Jenkins

Un pipeline CI/CD efficace exécute les tests unitaires en premier, bloque le merge en cas d'échec et vise un feedback en moins de 5 minutes (principe fail fast). Chaque commit déclenche automatiquement votre suite de tests, détectant les régressions en minutes plutôt qu'en jours. Voici comment procéder avec les trois plateformes les plus populaires : GitHub Actions, GitLab CI et Jenkins.

Ce guide fait partie de notre dossier sur l'automatisation des tests : définition, outils et étapes pour automatiser vos tests logiciels.

Qu'est-ce qu'intégrer les tests automatisés dans un pipeline CI/CD ?

Cela signifie que vos tests automatisés s'exécutent tout seuls, sur une machine propre, chaque fois que quelqu'un pousse du code ou ouvre une pull request, et que leur résultat décide si le changement peut être fusionné ou déployé. L'intégration continue (CI) consiste à fusionner souvent de petits changements et à vérifier chacun par un build et une exécution de tests automatisés. La livraison ou le déploiement continu (CD) prolonge le même pipeline pour empaqueter et publier l'application une fois ces contrôles passés.

Pourquoi intégrer les tests dans CI/CD ?

Un test qui s'exécute seulement localement n'apporte qu'une protection partielle : sur le poste d'un développeur, il ne protège personne d'autre ; en CI, il protège toute l'équipe. Une régression détectée quelques minutes après le commit qui l'a introduite coûte peu à corriger, alors que la même régression découverte en production coûte cher et se voit des utilisateurs. L'intégration CI/CD garantit que chaque changement de code est validé dans un environnement neutre et reproductible, bloquant le merge en cas d'échec. C'est le filet de sécurité de votre équipe, avec trois garanties qu'une exécution locale n'offre pas :

Quels tests lancer à chaque étape du pipeline ?

Lancez d'abord les tests les plus rapides et les plus fiables, et les plus lents en dernier, pour que le pipeline échoue le plus tôt possible. C'est la logique de la pyramide des tests : beaucoup de tests unitaires, moins de tests d'API et d'intégration, et un petit nombre de tests de bout en bout sur les parcours utilisateur critiques.

Les tests d'API sont rapides et pointent directement l'endpoint défaillant. Notre comparatif des outils de test API (Postman, REST Assured, Playwright) explique lequel lancer dans votre pipeline.

GitHub Actions — Le plus accessible

GitHub Actions est intégré directement dans GitHub. Un fichier YAML dans .github/workflows/ suffit à définir votre pipeline. Gratuit pour les repos publics, généreux pour les privés.

Pour lancer vos tests dans GitHub Actions, créez un fichier de workflow YAML dans .github/workflows/, déclarez les événements qui le déclenchent et listez les étapes qui installent les dépendances et lancent les tests :

1. Déclencher : on: pull_request et on: push sur main ; ajoutez schedule pour une exécution nocturne et workflow_dispatch pour un lancement manuel.
2. Préparer : actions/checkout, puis actions/setup-node ou actions/setup-python avec le cache des dépendances activé.
3. Installer : npm ci ou pip install -r requirements.txt ; pour Playwright, npx playwright install --with-deps installe les navigateurs et leurs dépendances système.
4. Exécuter : npx playwright test, ou pytest --junitxml=report.xml pour une suite Python.
5. Garder les preuves : actions/upload-artifact avec if: always(), pour conserver rapports, traces et captures même quand le job échoue. Stockez les identifiants dans des secrets chiffrés, jamais dans le code des tests.
6. Imposer : dans les réglages du dépôt, déclarez le job comme vérification obligatoire (required status check) sur la branche main protégée.

GitHub Actions est gratuit pour les dépôts publics sur les runners standard hébergés par GitHub ; les dépôts privés disposent d'un quota mensuel de minutes incluses qui dépend de l'offre GitHub (source : documentation de facturation de GitHub Actions).

GitLab CI — La solution complète

GitLab CI est inclus dans la plateforme GitLab. La configuration se fait via .gitlab-ci.yml. Les pipelines GitLab supportent nativement les environnements Docker, les caches entre jobs et les artefacts de test.

Jenkins — Le standard d'entreprise

Jenkins est l'outil CI/CD le plus utilisé en entreprise. Hautement configurable via plugins (2000+), il s'adapte à tous les environnements. Le Jenkinsfile (Groovy DSL) définit le pipeline as code.

GitHub Actions, GitLab CI ou Jenkins : lequel choisir ?

Choisissez la plateforme qui héberge déjà votre code : GitHub Actions pour un dépôt GitHub, GitLab CI pour GitLab, et Jenkins quand il vous faut un serveur d'automatisation auto-hébergé que vous maîtrisez entièrement, typiquement dans un environnement d'entreprise on-premise. Les trois savent lancer n'importe quel framework de test, exécuter des jobs en parallèle et publier des rapports de test.

Bonnes pratiques CI/CD pour les tests

Comment garder un pipeline de tests rapide ?

Mettez en cache, parallélisez et planifiez, mais ne supprimez jamais de couverture pour gagner du temps. Un pipeline trop long finit par être contourné.

1. Mettez en cache les dépendances (npm, pip, binaires des navigateurs) d'une exécution à l'autre.
2. Parallélisez avec des jobs en matrice, le sharding de Playwright (npx playwright test --shard=1/4) ou pytest-xdist (pytest -n auto).
3. Ordonnez les étapes pour que les contrôles peu coûteux échouent avant le lancement des plus coûteux.
4. Déplacez les suites lentes, comme la régression multi-navigateurs complète et les tests de performance, vers une exécution nocturne.
5. Utilisez des conteneurs pour les bases de données et les services dépendants, afin que chaque exécution parte d'un état connu.
6. Préparez les données de test par l'API plutôt que par l'interface.

Comment gérer les tests instables en CI ?

Traitez un test instable (flaky) comme un bug : isolez-le, trouvez la cause et corrigez-la, au lieu de relancer le pipeline jusqu'à ce qu'il passe au vert. Dès que les échecs sont ignorés par habitude, une vraie régression passe inaperçue.

Les causes habituelles sont les pauses fixes (sleep) au lieu d'attendre une condition, les tests qui dépendent des données des autres, les environnements partagés et les sélecteurs instables. Les relances aident au diagnostic : Playwright signale comme « flaky » un test qui échoue puis réussit à la relance, et sa trace (trace: 'on-first-retry') enregistre ce qui s'est passé. Donnez un responsable à chaque test mis en quarantaine. Notre guide des bonnes pratiques de l'automatisation des tests détaille les règles de conception qui évitent l'instabilité dès le départ.

Conclusion

Commencez simple : un workflow GitHub Actions qui exécute vos tests unitaires et d'API existants (par exemple pytest) sur chaque PR, déclaré comme vérification obligatoire, puis ajoutez des tests de bout en bout sur deux ou trois parcours critiques. Ajoutez progressivement la parallélisation, les tests d'intégration et les rapports. L'objectif est un feedback rapide (< 5 minutes pour les tests critiques) et fiable. Pour savoir si l'automatisation sera rentable dans votre équipe, faites le calcul avec notre calculateur de ROI de l'automatisation des tests.

Questions fréquentes