TDD en JavaScript : comment arrêter d'avoir peur des bugs et commencer à coder en toute confiance

Pourquoi le TDD n'est pas une tendance à la mode, mais votre nouveau meilleur ami

Imaginez : vous écrivez du code, tout fonctionne parfaitement. Vous lancez l'application — pas de bugs. Une semaine plus tard, vous ajoutez une nouvelle fonctionnalité, et... tout casse. Cela vous dit quelque chose ? Si vous avez déjà passé des heures à chercher une erreur apparue à cause d'un changement accidentel dans un module voisin — cet article est pour vous.

Le développement piloté par les tests (Test-Driven Development, TDD) n'est pas simplement une méthodologie, c'est une véritable bouée de sauvetage pour le développeur. Dans le monde de JavaScript, où le code change plus vite que la météo, le TDD vous aide à rester à flot. Voyons comment cela fonctionne, et pourquoi après le TDD, vous ne pourrez plus écrire de code comme avant.

Qu'est-ce que le TDD en réalité ? (Spoiler : ce n'est pas à propos des tests)

Beaucoup pensent que le TDD consiste simplement à "écrire des tests avant le code". Mais en réalité, c'est une philosophie de conception. Le TDD vous oblige à réfléchir à la manière dont votre code sera utilisé, avant de l'écrire. C'est comme un architecte qui dessine d'abord le plan du bâtiment, puis commence à construire.

Le cycle TDD se compose de trois étapes (souvent appelées "Red-Green-Refactor") :

\n
• Red : Écrivez un test qui échouera volontairement (car la fonctionnalité n'existe pas encore).
\n
• Green : Écrivez le code minimal pour que le test réussisse.
\n
• Refactor : Améliorez le code sans changer son comportement (les tests garantissent que vous n'avez rien cassé).
\n

Et oui, ce cycle se répète pour chaque petite unité de fonctionnalité. Cela semble ralentir ? Peut-être. Mais sur la distance, vous économiserez des heures de débogage.

Pourquoi JavaScript est idéal pour le TDD

JavaScript est un langage dynamique. C'est sa force et sa faiblesse. Les erreurs d'exécution sont courantes, surtout dans les grands projets. Le TDD transforme JavaScript d'un outil "flexible mais fragile" en une plateforme fiable.

De plus, l'écosystème JS est riche en outils de test : Jest, Mocha, Chai, Jasmine. Nous utiliserons Jest — il est simple, puissant et populaire. Si vous n'êtes pas encore familier avec Jest, ne vous inquiétez pas : nous commencerons par les bases.

Pratique : écrivons une calculatrice avec le TDD

La théorie c'est bien, mais passons au code réel. Nous allons écrire une calculatrice simple en utilisant le TDD. C'est un exemple classique, mais il démontre parfaitement le processus.

Étape 1 : Configuration du projet

Créez un nouveau dossier et initialisez le projet :

mkdir tdd-calculator\ncd tdd-calculator\nnpm init -y\nnpm install --save-dev jest\n

Ajoutez le script dans package.json :

"scripts": {\n  "test": "jest"\n}\n

Étape 2 : Rouge — écrivons un test pour l'addition

Créez le fichier calculator.test.js :

// calculator.test.js\nconst { add } = require('./calculator');\n\ndescribe('Calculator', () => {\n  test('adds 2 + 3 to equal 5', () => {\n    expect(add(2, 3)).toBe(5);\n  });\n});\n

Lancez le test : npm test. Il échouera avec une erreur, car la fonction add n'existe pas. C'est normal — c'est la phase rouge.

Étape 3 : Vert — écrivons le code minimal

Créez calculator.js :

// calculator.js\nfunction add(a, b) {\n  return a + b;\n}\n\nmodule.exports = { add };\n

Relancez le test. Vert ? Parfait ! Nous venons de passer la phase verte.

Étape 4 : Refactoring

Le code est simple, rien à refactoriser. Mais imaginez que nous voulions ajouter une vérification de type. Le TDD permet de le faire en toute sécurité : d'abord le test, ensuite le code.

// calculator.test.js\ntest('throws error if arguments are not numbers', () => {\n  expect(() => add('2', 3)).toThrow('Arguments must be numbers');\n});\n

Maintenant, modifions add :