Aller au contenu

Exécution des tests automatisés

Objectifs pédagogiques

À la fin de cette page, vous serez capable de :

  • comprendre comment les tests sont exécutés
  • distinguer exécution locale et exécution automatisée
  • interpréter les résultats de test
  • identifier les erreurs courantes
  • comprendre le rôle de l’exécution des tests dans un projet professionnel

Comment s’exécutent les tests automatisés ?

Les tests automatisés sont exécutés à différents moments du cycle de développement :

  • en local, par le développeur
  • automatiquement lors du développement collaboratif
  • avant une mise en production

👉 Leur objectif principal est de fournir un feedback rapide et fiable sur l’état du logiciel.

▶ Exécution locale des tests

L’exécution locale consiste à lancer les tests sur sa propre machine.

Elle est utilisée pour :

  • vérifier une nouvelle fonctionnalité
  • valider une correction de bug
  • éviter de casser l’existant avant un commit

Dans un projet backend, cela concerne souvent :

  • les tests unitaires
  • les tests d’API
  • certains tests d’intégration

🎯 Avantage principal : feedback immédiat pour le développeur.

Exemple fil rouge – MyEvents

Dans l’application MyEvents, un développeur peut lancer les tests localement pour vérifier que :

  • l’achat d’un billet fonctionne toujours
  • une modification sur le paiement n’a pas cassé l’API
  • les règles de validation sont respectées

👉 Les tests locaux servent de première barrière contre les régressions.

Exécution automatisée (CI / CD)

Les tests peuvent être exécutés automatiquement via des outils d’intégration continue (CI) :

  • à chaque commit
  • lors d’une pull request
  • avant un déploiement

Cette exécution permet de :

  • détecter les erreurs introduites par une modification
  • empêcher l’intégration de code défectueux
  • garantir une qualité minimale partagée par toute l’équipe

👉 Un test qui échoue peut bloquer un déploiement.

Interpréter les résultats de test

Lors de l’exécution des tests, on obtient généralement :

  • le nombre de tests exécutés
  • les tests réussis / échoués
  • les messages d’erreur
  • parfois une couverture de code

Il est essentiel de : - comprendre pourquoi un test échoue - distinguer un bug réel d’un problème de test - corriger rapidement les échecs

⚠️ Erreurs fréquentes lors de l’exécution des tests

  • tests dépendants entre eux
  • environnement non maîtrisé
  • données non réinitialisées
  • tests trop lents
  • tests instables (heure, réseau, API externe)

👉 Ces problèmes nuisent à la confiance dans les tests.

Lien avec la documentation et la traçabilité

Les résultats d’exécution des tests doivent être :

  • conservés
  • compréhensibles
  • exploitables

Ils alimentent : - la documentation de test - la traçabilité exigences ↔ tests - les décisions de mise en production

👉 C’est l’objet du chapitre suivant.

Exemple fil rouge – MyEvents

Dans l’application MyEvents, une exigence peut être formulée ainsi :

Lorsqu’un utilisateur achète un billet, le paiement doit être validé et un ticket doit être créé.

Cette exigence peut être tracée vers plusieurs tests automatisés :

  • test API POST /tickets/purchase (happy path)
  • test d’erreur : paiement refusé
  • test de régression après modification du module paiement

Chaque test est : - nommé explicitement - lié à l’exigence fonctionnelle - vérifiable dans les rapports d’exécution

👉 Cette traçabilité permet de savoir exactement ce qui est couvert,
et ce qui est impacté en cas d’évolution.

⬅ Frameworks et structure GWT ➡ Documentation et traçabilité des tests