08 - Glossaire général des tests
Ce glossaire regroupe les termes des trois series : Tests fondamentaux, Tests de performance et Tests en pratique. Si tu tombes sur un mot inconnu dans un article, c'est ici qu'il faut regarder.
Approval Testing
Technique qui consiste a capturer la sortie d'un programme et a la figer comme référencé. Les executions suivantes comparent leur sortie a cette référencé. Tout ecart fait échouer le test. Utile pour tester du legacy code sans le comprendre en profondeur. Aussi appele Golden Master.
Arrange-Act-Assert (AAA)
Structure en trois étapes pour écrire un test lisible. Arrange : preparer les donnees. Act : exécuter l'action testee. Assert : vérifier le résultat. C'est la meme idee que Given-When-Then du BDD, avec un vocabulaire technique. Voir les tests unitaires avec Bun.
BDD (Behavior-Driven Development)
Approche de développement ou les tests sont ecrits sous forme de comportements métier. Syntaxe Given-When-Then. L'objectif est que les non-techniques puissent lire et valider les specs. Voir TDD vs BDD vs test-after.
Bisect
Commande git (git bisect) qui effectue une recherche dichotomique dans l'historique pour trouver le commit qui a introduit un bug. En 6-7 étapes pour 100 commits, tu identifies le coupable. Voir tests de regression.
Breakpoint
Point d'arrêt place dans le code source. Le debugger interrompt l'exécution a cet endroit, permettant d'inspecter les variables et le flux d'exécution. Utile pour diagnostiquer un test qui echoue sans raison évidente.
Characterization Test
Test écrit pour documenter le comportement actuel d'un code existant, sans jugement sur si ce comportement est correct. Si le code a un bug, le test le capture aussi. Première étape pour ajouter des tests a du legacy code.
CI/CD (Continuous Intégration / Continuous Deployment)
Pratique d'automatisation ou chaque push déclenché un pipeline qui compile, teste et (optionnellement) deploie le code. La CI vérifié que le code est correct, la CD le met en production. Voir les tests dans un pipeline CI/CD et la serie déploiement GitLab.
Code Coverage
Metrique qui mesure le pourcentage de code exécuté pendant les tests. Se decline en coverage de lignes, de branches, de fonctions et de statements. Utile comme indicateur, dangereux comme objectif. Voir le piège du 100%.
Co-location
Pratique de placer le fichier de test a cote du fichier source (order.ts et order.test.ts dans le meme dossier). Recommandee pour les tests unitaires. Voir organiser ses tests.
E2e (End-to-End)
Test qui vérifié un parcours utilisateur complet, du navigateur a la base de donnees. Le plus coûteux en temps et en maintenance, mais le plus realiste. Utilise un vrai navigateur (Playwright, Cypress). Voir les tests e2e avec Playwright.
Factory
Fonction helper qui créé des objets de test avec des valeurs par défaut raisonnables. Accepte un paramètre overrides pour personnaliser les champs pertinents au test en cours. Voir organiser ses tests.
Fixture
Donnees preconstruites utilisees comme entree de test. Peut etre un fichier JSON, un seed de base de donnees, ou un objet créé par une factory. Le terme désigné tout le contexte nécessaire a l'exécution d'un test.
Flaky Test
Test qui passe et echoue aleatoirement sans changement de code. Causes courantes : timing, état partage, dépendances externes. Poison pour la confiance dans le pipeline. Voir flaky tests.
Golden Master
Synonyme d'Approval Testing. La sortie "approuvee" du programme, figee comme référencé. Toute deviation future déclenché un échec de test.
Green / Red / Refactor
Le cycle du TDD. Red : écrire un test qui echoue. Green : écrire le code minimal pour le faire passer. Refactor : ameliorer le code sans changer le comportement. Voir TDD vs BDD vs test-after.
Happy Path
Le scénario ou tout se passe bien. L'utilisateur entre des donnees valides, le serveur répond, la base est accessible. Tester le happy path est le minimum. Les vrais bugs sont souvent dans les chemins alternatifs (erreurs, timeouts, donnees invalides).
Intégration Test
Test qui vérifié l'interaction entre plusieurs composants. Typiquement : code + base de donnees, code + API externe, code + système de fichiers. Plus lent qu'un test unitaire, plus realiste. Voir les tests d'intégration.
k6
Outil open-source de tests de charge écrit en Go, scriptable en JavaScript. Permet de simuler des centaines de virtual users et de mesurer les temps de réponse. Voir la serie tests de performance.
Legacy Code
Selon Michael Feathers : du code sans tests. Pas nécessairement du vieux code ou du mauvais code. Du code qu'on ne peut pas modifier en confiance parce qu'il n'y a pas de filet de sécurité. Voir tester du legacy.
Load Test
Test de performance qui mesure le comportement du système sous charge normale et croissante. "Est-ce que l'API répond en moins de 200ms avec 100 utilisateurs simultanes ?" Voir les scénarios k6.
Memory Leak
Fuite de mémoire. Le programme alloue de la mémoire sans la libérer. Indolore au début, fatal sur la duree. Les soak tests sont conçus pour les détecter. Voir profiling mémoire.
Mock
Objet qui remplace une vraie dépendance dans un test. Un mock enregistre les appels reçus et peut retourner des valeurs configurees. Strictement, un mock vérifié qu'il a ete appele correctement (contrairement au stub). En pratique le terme est souvent utilise pour tout type de test double. Voir les mocks et stubs.
p95 / p99
Percentiles de latence. p95 = 95% des requêtes repondent en moins de X ms. p99 = 99% des requêtes repondent en moins de X ms. Plus fiable que la moyenne pour évaluer les performances, parce que la moyenne masque les pics. Voir les benchmarks avec Bun.
Pipeline
Sequence d'étapes automatisees déclenchée par un push ou une merge request. Typiquement : lint -> tests unitaires -> tests d'intégration -> e2e -> deploy. Voir les tests dans un pipeline CI/CD et la config GitLab CI.
Quarantine
Technique de gestion des flaky tests. Un test marque en quarantaine est temporairement désactivé (.skip) avec un ticket associe. Evite de polluer le pipeline tout en gardant une trace du problème.
Regression Test
Test écrit spécifiquement pour reproduire un bug corrige, afin qu'il ne revienne jamais. Le workflow : bug reporte -> test rouge -> fix -> test vert -> protection permanente. Voir tests de regression.
Smoke Test
Test rapide et superficiel qui vérifié que le système démarré et répond. Pas de vérification approfondie, juste "est-ce que ca tourne ?". Souvent le premier test apres un déploiement.
Snapshot
Fichier qui capture la sortie d'un test a un instant T. Les executions suivantes comparent leur sortie au snapshot. Si ca différé, le test echoue. Utile pour les réponses JSON, le rendu HTML, les exports CSV. Voir les snapshot tests.
Soak Test
Test d'endurance. Charge moderee sur une longue duree (heures, jours). Detecte les fuites de mémoire, la degradation progressive, les connexions non fermees. Voir tests d'endurance.
Spy
Test double qui enregistre les appels reçus sans modifier le comportement de la fonction originale. "Est-ce que cette fonction a ete appelee 3 fois avec ces arguments ?" La fonction réelle s'exécuté quand meme.
Strangler Fig
Pattern de migration incrementale. On entoure le vieux système de tests depuis l'extérieur, puis on remplace progressivement les internals. Le nom vient du figuier etrangleur qui pousse autour d'un arbre existant. Applicable aux tests de legacy. Voir tester du legacy.
Stress Test
Test de performance qui pousse le système au-delà de ses limites pour observer comment il reagit. "A quel moment l'API renvoie des 503 ? Est-ce qu'elle récupéré apres ?" Voir stress et limites.
Stub
Test double qui retourne des valeurs predefinies sans logique. Contrairement au mock, le stub ne vérifié pas comment il a ete appele. Il fournit des donnees de test, c'est tout. Voir les mocks et stubs.
TDD (Test-Driven Development)
Méthode de développement ou les tests sont ecrits avant le code. Cycle Red-Green-Refactor. Force un design incrementiel et garantit une couverture naturelle. Particulierement utile pour la logique métier complexe. Voir TDD vs BDD vs test-after.
Test Double
Terme générique pour tout objet qui remplace une vraie dépendance dans un test. Regroupe les mocks, stubs, spies, fakes et dummies. Le terme vient de Gerard Meszaros dans "xUnit Test Patterns".
Threshold
Seuil d'acceptation dans un test de performance. "Le p95 doit etre inférieur a 200ms." Si le seuil est dépassé, le test echoue. Configurable dans k6, dans les coverage reporters, ou dans la CI.
Unit Test
Test qui vérifié une unité de code en isolation. Pas de base de donnees, pas de réseau, pas de filesystem. Rapide (millisecondes), nombreux, et premier filet de sécurité. Voir les tests unitaires avec Bun.
Virtual User (VU)
Utilisateur simule dans un test de charge. Chaque VU exécuté un scénario complet (requêtes HTTP, pauses). k6 permet d'en configurer des centaines en parallèle pour simuler du trafic realiste. Voir k6 introduction.
Article précédent : 07 - Organiser ses tests dans un projet
Series liees
- Tests fondamentaux : les bases des tests, de l'unitaire au e2e
- Tests de performance : benchmarks, charge, stress, endurance
- Déploiement GitLab CI : mettre en place le pipeline
- Architecture hexagonale : structurer le code pour qu'il soit testable