Outils & qualité · 4 mondes · 12 étapes

Tests & déploiement

Des tests qui attrapent les bugs, une chaîne qui vérifie tout, une mise en production sans frayeur.

Progression

0 %

0/12 étapes terminées

← Décryptages

Fondamental · 9 min de lecture

Écrire des tests

Des tests jugés sur les bugs qu'ils attrapent

1Définition

Un test automatique prépare des données, appelle le code, puis vérifie le résultat avec des assertions qui lèvent une erreur explicite en cas d'écart. Une bonne suite couvre le cas normal, les limites et les erreurs ; on la juge aux bugs qu'elle attrape — c'est l'idée du test de mutation.

2Principes fondamentaux

01

Préparer, agir, vérifier

Trois temps lisibles dans chaque test : les données, l'appel, l'assertion.

02

Comparer des valeurs

=== compare les références des objets : l'égalité de test compare le contenu.

03

Tester les frontières

Pile au seuil, juste en dessous, vide, zéro : là où > et >= se distinguent.

04

Un échec n'arrête pas la série

Le lanceur continue, pour montrer tous les tests rouges d'un coup.

3Exemples pratiques

Avec Vitest

Exemple
1import { describe, expect, it } from "vitest";2import { remise } from "./remise";3 4describe("remise", () => {5  it("applique VIP pile au seuil", () => {6    expect(remise(50, "VIP")).toBe(40);7  });8  it("refuse un prix négatif", () => {9    expect(() => remise(-5, "VIP")).toThrow();10  });11});

Mêmes idées que dans le cours : des cas nommés, des assertions, et un test d'erreur attendue.

Le test de mutation automatique

Exemple
1npx stryker run2# Mutant survived: src/remise.ts:4  >= → >

Stryker modifie le code tout seul (inverse des conditions, change des opérateurs) et signale chaque mutant que les tests n'ont pas attrapé.

4Erreurs courantes

Un seul cas « qui marche »

À éviter

expect(remise(100, "ETE10")).toBe(90);  // et c'est tout

À faire

Normal, limites, code inconnu, erreur

Pourquoi : La moitié des règles n'est jamais vérifiée.

Comparer des objets avec toBe

À éviter

expect(panier).toBe([{ prix: 10 }]);

À faire

expect(panier).toEqual([{ prix: 10 }]);

Pourquoi : toBe compare les références : deux tableaux identiques sont différents.

Tester l'implémentation

À éviter

expect(fonctionInterne).toHaveBeenCalled();

À faire

expect(resultat).toBe(40);

Pourquoi : Un test lié aux détails casse à chaque réécriture, même quand le comportement ne change pas.

5Subtilités à connaître

  • ◆Le taux de couverture dit quelles lignes ont été exécutées, pas si elles ont été vérifiées : une suite peut couvrir 100 % du code sans une seule assertion utile.
  • ◆Écrire le test avant le code (TDD) oblige à penser aux cas avant d'être influencé par sa propre implémentation.
  • ◆Un test qui échoue doit dire pourquoi : « Attendu 40, reçu 50 » se corrige en une minute, « false is not true » en une heure.

6Vérifie ta compréhension

Question 1/3

Score 0

Quel cas attrape un > écrit à la place de >= ?

Envie d'essayer ? Ouvre le Labo et recopie les exemples pour les modifier.