09 - Glossaire
Ce que tu vas trouver ici
Tous les termes techniques utilises dans cette serie, classes par ordre alphabetique. Chaque terme a une définition courte et un exemple concret. Reviens ici quand tu croises un mot inconnu.
Prerequisites
Ce glossaire est conçu pour etre consulte a tout moment. Il est plus utile apres avoir parcouru les articles précédents.
Arrange-Act-Assert (AAA)
Le pattern de structure d'un test. Arrange : preparer les donnees. Act : exécuter l'action testee. Assert : vérifier le résultat. Chaque test devrait suivre ces trois étapes dans cet ordre.
typescriptit("applies discount", () => {
// Arrange
const price = 100;
// Act
const result = applyDiscount(price, 20);
// Assert
expect(result).toBe(80);
});
Voir article 02.
Assertion
Une vérification dans un test. "J'affirme que cette valeur est egale a 42." Si l'assertion echoue, le test echoue. En Bun, c'est la chaîne expect(value).toBe(42).
beforeEach / afterEach
Hooks qui s'executent avant et apres chaque test d'un bloc describe. beforeEach sert a preparer un état propre. afterEach sert au nettoyage (fermer des connexions, restaurer des mocks).
typescriptbeforeEach(() => {
cart = new ShoppingCart();
});
Code Coverage (couverture de code)
Mesure du pourcentage de code exécuté par les tests. Exprimee en lignes, branches ou fonctions. 80% de couverture sur la logique métier est un bon objectif. 100% est rarement utile.
bashbun test --coverage
describe / it
Les deux fonctions de structure des tests. describe groupe des tests lies. it (ou test) definit un test individuel. On peut imbriquer les describe.
typescriptdescribe("OrderService", () => {
describe("create", () => {
it("saves the order", () => { /* ... */ });
it("sends confirmation", () => { /* ... */ });
});
});
E2E (End-to-End)
Test qui simule un vrai utilisateur. Un navigateur s'ouvre, clique, remplit des formulaires, vérifié ce qui s'affiche. Lent mais tres realiste. On utilise Playwright pour ca. Voir article 06.
Fake
Une implementation simplifiee mais fonctionnelle d'une interface. Contrairement au mock qui enregistre des appels, le fake fait vraiment le travail, mais en mémoire. L'InMemoryOrderRepository qui stocke dans une Map au lieu de PostgreSQL est un fake. Voir article 03.
Fixture
Donnees de test predefinies. Un utilisateur de test, une commande de test, un jeu de donnees pour un scénario spécifique. Les fixtures rendent les tests reproductibles et lisibles.
typescriptconst testUser = {
id: "user-123",
email: "alice@test.com",
name: "Alice",
role: "admin",
};
Flaky Test
Un test qui passe parfois et echoue parfois sans qu'on ait change le code. Les causes habituelles : dépendance au temps (Date.now()), ordre d'exécution non déterministe, race conditions, dépendance réseau. Les flaky tests sont le cancer d'une suite de tests. Si tu en as un, corrige-le ou supprime-le.
Green / Red
En TDD, "red" signifie que le test echoue (on l'écrit avant le code). "Green" signifie que le test passe (on a écrit le code qui le satisfait). Le cycle TDD est : Red, Green, Refactor.
Happy Path
Le scénario ou tout se passe bien. L'utilisateur entre des donnees valides, le serveur répond, la commande est créée. C'est le premier test qu'on écrit, mais il ne suffit pas. Les bugs vivent dans les cas limites (donnees vides, nulls, doublons).
Intégration Test (test d'intégration)
Test qui vérifié que plusieurs composants fonctionnent ensemble. Typiquement : ton code + une base de donnees, ou ton service + une API externe. Plus lent qu'un unitaire, mais attrape les bugs de communication entre composants. Voir article 04.
Matcher
La méthode chaînée apres expect() qui definit la comparaison. toBe, toEqual, toContain, toThrow, toBeNull, etc. Chaque matcher teste une chose spécifique.
typescriptexpect(value).toBe(42); // egalite stricte
expect(obj).toEqual({ a: 1 }); // egalite profonde
expect(arr).toContain("hello"); // contient un element
Mock
Une fonction créée de toutes pieces avec mock() pour remplacer une dépendance. Le mock enregistre les appels (arguments, nombre de fois) pour que tu puisses vérifier les interactions.
typescriptconst sendEmail = mock(() => Promise.resolve());
await createOrder(sendEmail);
expect(sendEmail).toHaveBeenCalledTimes(1);
Voir article 03.
Parameterized Test (test paramètre)
Un test exécuté plusieurs fois avec des jeux de donnees différents. Evite la duplication quand la logique du test est identique mais les valeurs changent.
typescriptconst cases = [
{ input: 100, discount: 10, expected: 90 },
{ input: 200, discount: 50, expected: 100 },
];
for (const { input, discount, expected } of cases) {
it(`${input} - ${discount}% = ${expected}`, () => {
expect(applyDiscount(input, discount)).toBe(expected);
});
}
Regression Test (test de regression)
Un test écrit apres avoir corrige un bug, pour s'assurer que ce bug ne revient jamais. Tu reproduis le bug dans un test (red), tu le corriges (green), tu gardes le test pour toujours. C'est la meilleure assurance anti-regression.
Snapshot
Un test qui capture la sortie d'une fonction et la compare a une version sauvegardee. Utile pour du HTML, des configs générées, des sorties CLI. Dangereux pour des objets larges ou instables. Voir article 08.
Spy
Un wrapper autour d'une vraie fonction qui enregistre les appels sans modifier le comportement. La fonction originale s'exécuté normalement.
typescriptconst spy = spyOn(console, "log");
doSomething();
expect(spy).toHaveBeenCalledWith("message");
spy.mockRestore();
Stub
Une doublure qui remplace une fonction par une valeur de retour fixe. La vraie implementation ne s'exécuté pas.
typescriptconst stub = spyOn(api, "fetch").mockReturnValue(
Promise.resolve({ temp: 22 })
);
SUT (System Under Test)
Le code qu'on teste. Dans un test unitaire, c'est une fonction ou une classe. Dans un test fonctionnel, c'est un use case. Dans un test e2e, c'est l'application complète.
TDD (Test-Driven Development)
Méthode ou tu ecris le test avant le code. Le cycle : ecris un test qui echoue (red), ecris le minimum de code pour le faire passer (green), ameliore le code sans casser le test (refactor). Repete.
TDD n'est pas obligatoire pour bien tester. Mais c'est un exercice formateur. Je le pratique surtout sur la logique métier complexe, pas sur le CRUD.
Test Double
Le terme générique pour toute doublure utilisee dans un test : mock, stub, spy, fake. Gerard Meszaros a défini ce vocabulaire dans xUnit Test Patterns.
Test Runner
L'outil qui decouvre, exécuté et rapporte les résultats des tests. Dans notre cas, c'est bun test (le runner natif de Bun). D'autres exemples : Jest, Vitest, Mocha.
Threshold (seuil)
Un seuil minimum de couverture de code. Si la couverture tombe en dessous (par exemple 80%), le build echoue. C'est un garde-fou pour éviter que la couverture se degrade avec le temps. Utile en CI, mais le chiffre exact importe moins que la tendance.
Unit Test (test unitaire)
Test d'une seule unité de logique, isolee de toute dépendance externe. Rapide (millisecondes), déterministe, sans effet de bord. C'est la base de toute stratégie de test. Voir article 02.
Navigation de la serie
| # | Article |
|---|---|
| 00 | Introduction |
| 01 | La pyramide des tests |
| 02 | Tests unitaires avec bun test |
| 03 | Mocks, stubs, fakes et spies |
| 04 | Tests d'intégration |
| 05 | Tests fonctionnels |
| 06 | Tests e2e avec Playwright |
| 07 | Tests de contrat d'API |
| 08 | Snapshot testing |
| 09 | Glossaire (tu es ici) |
Article précédent : 08 - Snapshot testing