00 - Pourquoi tester (et pourquoi on ne le fait pas)
Ce que tu vas apprendre
- Combien coûte l'absence de tests (en vrai, avec des chiffres)
- Les excuses classiques et pourquoi elles ne tiennent pas
- Ce que cette serie couvre et les outils qu'on va utiliser
Prerequisites
Savoir lire du TypeScript. Avoir Bun installe (curl -fsSL https://bun.sh/install | bash).
Le deploy du vendredi soir
Décembre 2023. Vendredi, 17h30. Je pousse une "petite correction" en prod sur paltemps.fr. Un changement de 4 lignes dans une fonction de calcul de prix. Rien de mechant.
Samedi matin, message d'un utilisateur : "les totaux sont tous a zero". Panique. Je me connecte, je regarde les logs, je trouve le bug en 12 minutes. Une multiplication par undefined au lieu de quantity. Le fix prend 30 secondes.
Mais les commandes passees entre vendredi soir et samedi matin ? Toutes avec un total a zero. Il a fallu les reprendre une par une. Trois heures de boulot un samedi pour un bug qu'un test de 3 lignes aurait attrape :
typescriptit("calculates total with quantity", () => {
expect(calculateTotal([{ price: 10, qty: 2 }])).toBe(20);
});
Trois lignes. Temps d'exécution : 2 millisecondes.
Ce que coûte l'absence de tests
Le problème n'est jamais le bug lui-meme. C'est le coût en cascade :
- Temps de debug : trouver un bug en prod prend 5 a 20 fois plus de temps qu'en dev. Pas d'environnement isole, pas de stack trace propre, des donnees reelles corrompues.
- Confiance perdue : apres deux bugs en prod, l'équipe devient paranoiaque. Chaque deploy devient un événement stressant. On deploie moins souvent. Les features s'accumulent. Les merges deviennent énormes. Les bugs augmentent.
- Regression : tu corriges un bug, tu en créés un autre. Sans tests, c'est un jeu de taupe permanent.
IBM a mesure que corriger un bug en prod coûte 100 fois plus que le corriger pendant le développement. Meme si le chiffre exact est discutable, l'ordre de grandeur est la.
Les excuses classiques
"J'ai pas le temps". Tu as le temps de debugger en prod un samedi matin ? Écrire un test unitaire prend 2 a 5 minutes. Debugger un bug en prod sans tests prend 30 minutes a 3 heures. Fais le calcul.
"Ca marche sur ma machine". Oui. Et en staging ? Et en prod avec des donnees reelles ? Et quand ton collegue modifie la fonction que tu utilises ? Un test automatise tourne partout, tout le temps, sans oublier de cas.
"Je teste manuellement". Super. Tu vas cliquer sur 47 boutons apres chaque commit ? Et quand le projet aura 200 routes, tu feras quoi ? Le test manuel ne scale pas.
"Les tests ralentissent le dev". Au début, oui. Tu investis 10 minutes maintenant pour gagner des heures plus tard. C'est comme mettre sa ceinture de sécurité : ca prend 3 secondes et tu ne le regrettes jamais.
"Mon projet est trop petit". Justement. C'est maintenant que c'est facile de commencer. Attendre que le projet ait 50 fichiers pour ajouter des tests, c'est comme attendre que la maison brûlé pour acheter un extincteur.
Le retour sur investissement
Voici ce que j'observe sur mes projets depuis que je teste systématiquement :
- Les bugs en prod ont baisse de 80%. Pas zero, mais nettement moins.
- Le refactoring est devenu possible. Avant, personne n'osait toucher au code existant. Maintenant, je change une fonction, je lance les tests, je sais en 2 secondes si j'ai casse quelque chose.
- Les deploys sont ennuyeux. Et c'est exactement ce qu'on veut. Un deploy, ca devrait etre un non-événement.
Ce que couvre cette serie
On va construire ensemble une culture du test, article par article :
| # | Sujet | Contenu |
|---|---|---|
| 00 | Introduction | Pourquoi tester (tu es ici) |
| 01 | Pyramide des tests | Unit, intégration, e2e : combien de chaque |
| 02 | Tests unitaires | bun test, assertions, structure |
| 03 | Mocks et spies | Mocks, stubs, fakes, spies avec Bun |
| 04 | Intégration | Tester avec une vraie base de donnees |
| 05 | Tests fonctionnels | Valider des use cases complets |
| 06 | E2E avec Playwright | Tests navigateur de bout en bout |
| 07 | Contrat d'API | Verifier les réponses de ton API |
| 08 | Snapshots | Quand c'est utile, quand c'est un piège |
| 09 | Glossaire | Tous les termes expliques |
Notre outil : `bun test`
On utilise le test runner natif de Bun. Pas Jest, pas Vitest. Bun a un runner intégré, compatible avec les API Jest (describe, it, expect, mock, spyOn), et il est rapide. Vraiment rapide.
bash# Lancer tous les tests
bun test
# Lancer un fichier specifique
bun test math.test.ts
# Avec couverture de code
bun test --coverage
Les imports viennent de "bun:test" :
typescriptimport { describe, it, expect } from "bun:test";
Pas de config. Pas de jest.config.ts. Pas de vitest.config.ts. Ca marche direct.
Pour les tests e2e, on utilisera Playwright. Mais on verra ca dans l'article 06.
Par ou commencer
Si tu n'as jamais écrit un test, commence par l'article suivant sur la pyramide des tests pour comprendre la stratégie globale. Puis passe a l'article 02 pour écrire tes premiers tests unitaires.
Si tu testes deja mais que tu veux structurer ta pratique, saute directement aux articles qui t'interessent.
Article suivant : 01 - La pyramide des tests