Frameworks de test et structure Given / When / Then

"Un bon test raconte une histoire : contexte, action, résultat."

Principe des tests lisibles (BDD / GWT)

Objectifs pédagogiques

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

comprendre le rôle d’un framework de test
expliquer la structure Given / When / Then
relier GWT au formalisme AAA (Arrange / Act / Assert)
écrire des tests lisibles et structurés
faire le lien avec les tests backend (AdonisJS)
appliquer des bonnes pratiques pour maintenir les tests

Qu’est-ce qu’un framework de test ?

Un framework de test est un ensemble d’outils qui permet de :

écrire des tests de manière structurée
exécuter automatiquement une suite de tests
comparer les résultats attendus et obtenus (assertions)
produire des rapports (succès/échecs, détails, couverture)

👉 Il sert à standardiser la façon de tester dans une équipe et à rendre les tests répétables.

Tests backend avec AdonisJS (vue d’ensemble)

Dans un backend comme AdonisJS, les tests peuvent vérifier :

les routes HTTP (API)
les contrôleurs
les services métier
l’accès à la base de données
les règles de validation
la gestion des erreurs

🎯 L’objectif : vérifier que l’API se comporte correctement sans passer par une interface graphique.

Structure Given / When / Then (GWT)

La structure Given / When / Then permet de rendre un test lisible, même pour quelqu’un qui n’a pas écrit le code.

Given (Étant donné)

Préparer le contexte :

données initiales
utilisateur existant
état de la base
dépendances simulées

When (Quand)

Déclencher l’action :

appel de fonction
requête HTTP (GET/POST/PUT/DELETE)

Then (Alors)

Vérifier :

statut HTTP
contenu JSON
données en base
effets secondaires (email, log, etc.)

GWT et AAA : même logique, vocabulaire différent

On entend aussi souvent parler du formalisme AAA :

Arrange : préparer le contexte
Act : exécuter l’action
Assert : vérifier le résultat

C’est très proche de GWT :

GWT (BDD)	AAA (xUnit)	Idée
Given	Arrange	Préparer l’état initial
When	Act	Déclencher l’action testée
Then	Assert	Vérifier le résultat attendu

👉 GWT est souvent plus “narratif” (orienté scénario), alors que AAA est très courant dans les tests unitaires et frameworks xUnit.
Dans la pratique, on utilise souvent la même structure, quel que soit le nom.

Pourquoi utiliser GWT (ou AAA) ?

Cette structure est utile parce qu’elle :

force à structurer le test en 3 étapes claires
améliore la lecture et la relecture
facilite la collaboration (revue de code)
aide à relier tests ↔ exigences (traçabilité)

👉 Un test bien structuré = un test plus facile à corriger, maintenir et faire évoluer.

Exemple fil rouge – MyEvents (API backend)

Dans MyEvents, on a l’exigence suivante :

Lorsqu’un utilisateur achète un billet : - le paiement est validé - le billet est enregistré - une confirmation est envoyée - l’événement apparaît dans l’espace utilisateur

On peut traduire ça en test GWT / AAA.

✅ Exemple GWT (scénario API)

1) Exemple en langage naturel

Given un utilisateur connecté et un événement existant
When l’utilisateur appelle POST /tickets/purchase avec un paiement valide
Then l’API répond 201, un ticket est créé, et une confirmation est envoyée

2) Exemple en pseudo-code (inspiré backend)

Given un utilisateur U existe
And un événement E existe
And U est authentifié (token)

When U envoie POST /tickets/purchase avec eventId=E et paiement valide

Then réponse 201 Created
And la réponse contient ticketId
And un ticket est enregistré en base
And un e-mail de confirmation est déclenché

Exemple d’erreur (paiement refusé)

Un test utile est aussi un test négatif :

Given un utilisateur U existe et est authentifié
And un événement E existe

When U envoie POST /tickets/purchase avec paiement refusé

Then réponse 402 Payment Required (ou 400 selon choix API)
And aucun ticket n’est créé
And un message d’erreur clair est renvoyé
And aucun email n’est envoyé

👉 Ces tests valident la robustesse de l’API.

✅ Bonnes pratiques (tests backend)

Pour des tests automatisés efficaces et maintenables, il est recommandé de :

donner un nom explicite au test
(ce que l’on vérifie doit être compréhensible sans lire le code)
limiter un test à une seule idée principale
(un comportement = un test)
séparer clairement Given / When / Then (ou Arrange / Act / Assert)
(y compris visuellement dans le code)
utiliser des fixtures
(données connues, contrôlées et reproductibles)
plutôt que des données aléatoires
éviter les dépendances externes réelles
(paiement, e-mail, SMS, API tierce)
→ utiliser des mocks, stubs ou fakes
écrire des tests stables
(pas de dépendance à l’heure réelle, au réseau, ou à l’ordre d’exécution)

👉 Un test instable est pire qu’un test absent.

À retenir

un framework de test aide à écrire, exécuter et organiser les tests
GWT (ou AAA) rend les tests lisibles et professionnels
sur une API backend (ex. MyEvents avec AdonisJS), cette structure s’applique très bien
les scénarios négatifs sont aussi importants que les scénarios happy path

⬅ Tests automatisés ➡ Outils de tests automatisés