Développement piloté par les tests (TDD) avec Bun Test

Le développement piloté par les tests (TDD) est une méthodologie puissante pour écrire du code propre et sans bug. Dans cet article, nous explorerons comment implémenter TDD à l'aide du programme d'exécution de tests intégré de Bun, Bun Test, connu pour sa rapidité et sa simplicité.

Qu’est-ce que le TDD ?

Le développement piloté par les tests (TDD) est une pratique de développement logiciel dans laquelle les tests sont écrits avant le code. La pratique TDD guide la mise en œuvre et garantit la fonctionnalité à travers des cycles itératifs d'écriture, de test et de refactoring.

TDD est un processus de développement qui suit ces étapes :

• Écrivez un test pour la fonctionnalité souhaitée.
• Définissez tous les scénarios de tests que vous souhaitez couvrir.
• Exécutez le test et vérifiez qu'il échoue (car la fonctionnalité peut être incomplète ou ne pas encore couvrir tous les scénarios).
• Mettez à jour et refactorisez le code pour que le test réussisse tout en garantissant la réussite de tous les tests.

Ce processus itératif est conçu pour produire du code robuste et bien testé.

Configurer votre projet JavaScript avec Bun

Si vous n'avez pas installé Bun, installez-le en suivant les instructions de la documentation JavaScript de Bun.
Ensuite, initialisez un nouveau projet :

bun init

➜  example bun init
bun init helps you get started with a minimal project and tries to guess sensible defaults. Press ^C anytime to quit

package name (example):
entry point (index.ts):

Done! A package.json file was saved in the current directory.

Créez un fichier de test dans le répertoire tests (par exemple, tests/example.test.js). Bun détecte automatiquement les fichiers se terminant par .test.ts ou .test.js pour les tests.

mkdir tests
touch tests/example.test.js

Écrire votre premier test

Commençons par un exemple simple.
Nous allons créer un fichier de calculatrice pour implémenter certaines fonctions mathématiques.
Nous allons d’abord nous concentrer sur une fonction simple, comme sum(), même si JavaScript possède déjà un opérateur d’addition natif. Cela nous permet de nous concentrer sur la structuration des tests plutôt que sur la complexité de la logique.
Voici le plan :

• Créez un fichier calculator.ts dans lequel nous définirons une fonction sum() qui renvoie initialement 0.
• Écrivez des tests pour la fonction sum(), couvrant plusieurs cas de test.
• Exécutez les tests et confirmez qu'ils échouent.
• Mettez à jour la logique de la fonction sum() pour faire réussir les tests.
• Réexécutez les tests pour vous assurer que notre implémentation est correcte.

Créez votre fichier calculator.test.js

Dans le fichier tests/calculator.test.js, vous pouvez implémenter vos tests :

import { describe, expect, it } from "bun:test";
import { sum } from "../calculator";

describe("sum function", () => {
  it("should return the sum of two numbers (both are positive)", () => {
    expect(sum(2, 3)).toBe(5);
  });
  it("should return the sum of two numbers (one is negative)", () => {
    expect(sum(-1, 2)).toBe(1);
  });
});

Ces tests vérifient le comportement de la fonction sum(), définie dans le module calculatrice. Les tests sont écrits à l'aide de la bibliothèque de tests de Bun et organisés dans un bloc de description nommé « fonction somme ». Le bloc décrire() permet de regrouper les tests « similaires ». Chaque bloc it() spécifie un scénario particulier à tester. Voici ce que fait chaque test :

1. Test : Addition de deux nombres positifs
   • Description : "doit renvoyer la somme de deux nombres (les deux sont positifs)"
   • Ce test vérifie si la fonction somme calcule correctement la somme de deux entiers positifs.
   • Exemple : sum(2, 3) est attendu pour renvoyer 5.
2. Test : Ajout d'un nombre négatif et d'un nombre positif
   • Description : "doit renvoyer la somme de deux nombres (l'un est négatif)"
   • Ce test valide que la fonction somme gère correctement un scénario où un nombre est négatif.
   • Exemple : sum(-1, 2) est attendu pour renvoyer 1.

Ces tests garantissent que la fonction somme se comporte comme prévu pour les scénarios d'addition de base, couvrant à la fois les nombres positifs et les entrées mixtes (positives et négatives).

Créez votre fichier calculator.ts

Maintenant, vous pouvez créer votre module de calculatrice qui exportera la fonction sum().
Dans le fichier calculator.ts :

bun init

La première version de la fonction renvoie une valeur codée en dur, je m'attends donc à ce que les tests échouent.
Exécution des tests :

➜  example bun init
bun init helps you get started with a minimal project and tries to guess sensible defaults. Press ^C anytime to quit

package name (example):
entry point (index.ts):

Done! A package.json file was saved in the current directory.

Maintenant, nous pouvons ajuster la logique de la fonction sum() dans la calculatrice.ts ajuster la logique de la fonction sum() :

mkdir tests
touch tests/example.test.js

Maintenant, si vous lancez les tests, vous aurez un statut « vert » ✅.

Refactorisation des tests avec un ensemble de données

Si vous souhaitez exécuter les mêmes tests avec différents scénarios (valeurs d'entrée), vous pouvez utiliser la méthode each().

import { describe, expect, it } from "bun:test";
import { sum } from "../calculator";

describe("sum function", () => {
  it("should return the sum of two numbers (both are positive)", () => {
    expect(sum(2, 3)).toBe(5);
  });
  it("should return the sum of two numbers (one is negative)", () => {
    expect(sum(-1, 2)).toBe(1);
  });
});

En utilisant une approche basée sur un ensemble de données, ce code teste la fonction somme du module calculateur. La méthode it.each() est utilisée pour simplifier les cas de test répétitifs en itérant sur un ensemble de données d'entrées et de sorties attendues. Voici un aperçu de son fonctionnement :

Tout d'abord, vous pouvez définir un ensemble de données

export function sum(a: number, b: number) {
  // Function yet to be implemented
  return 0;
}

L'ensemble de données est un tableau de tableaux. Chaque tableau interne représente un cas de test, où les éléments correspondent à :

• a (premier numéro à ajouter),
• b (deuxième numéro à ajouter),
• attendu (le résultat attendu de sum(a, b)).

La fonction de description regroupe tous les tests liés à la fonction somme sous un seul bloc pour une meilleure organisation.

Dans le bloc décrire(), it.each(dataset) parcourt chaque ligne du tableau de l'ensemble de données.
"La somme de %d et %d doit être %d" est un modèle de description pour le test, où %d est remplacé par les nombres réels de l'ensemble de données à chaque itération.
Par exemple, la première itération génère la description : "La somme de 2 et 3 devrait être 5".

Dans la fonction de rappel (a, b, attendu), les éléments de chaque ligne de l'ensemble de données sont déstructurés en variables : a, b et attendu. Ensuite, dans le test, la fonction somme est appelée avec a et b, et le résultat est vérifié à l'aide de expect() pour s'assurer qu'il correspond à ce qui était attendu.

Pourquoi utiliser it.each() (ou test.each()) ?

• Efficacité : au lieu d'écrire des blocs it() ou test() séparés pour chaque cas, vous pouvez définir tous les cas de test dans un seul ensemble de données et les parcourir en boucle.
• Lisibilité : la logique de test est concise et l'ensemble de données facilite l'ajout ou la modification de cas de test sans dupliquer le code.
• Évolutivité : utile lorsque vous traitez plusieurs cas de test, en particulier lorsque la logique testée est similaire d'un cas à l'autre.

Autre exemple pratique : calculer la moyenne

Pour montrer un exemple supplémentaire pour TDD, implémentons une fonction moyenne dans le module de calculatrice qui calcule la moyenne (moyenne) d'un tableau de nombres. Suivant l'approche TDD, nous commencerons par écrire les tests.

Dans le calculator.test.js déjà existant, ajoutez ces tests spécifiques à la fonction Mean() :

bun init

Maintenant dans le fichier calculator.ts, ajoutez la fonction Mean() :

➜  example bun init
bun init helps you get started with a minimal project and tries to guess sensible defaults. Press ^C anytime to quit

package name (example):
entry point (index.ts):

Done! A package.json file was saved in the current directory.

Vous pouvez donc maintenant réexécuter les tests

mkdir tests
touch tests/example.test.js

Tous les tests devraient réussir.
Dans ce cas, l’implémentation est déjà testée, aucune refactorisation supplémentaire n’est donc nécessaire. Cependant, prenez toujours le temps de revoir votre code pour des améliorations.

Couverture des tests

La couverture des tests est une métrique qui mesure le pourcentage de votre base de code exécuté lors de tests automatisés. Il fournit un aperçu de la façon dont vos tests valident votre code.
La couverture du test Bun permet d'identifier la « couverture de ligne ».
La couverture de ligne vérifie si chaque ligne de code est exécutée pendant la suite de tests.

Exécution de la couverture de test :

import { describe, expect, it } from "bun:test";
import { sum } from "../calculator";

describe("sum function", () => {
  it("should return the sum of two numbers (both are positive)", () => {
    expect(sum(2, 3)).toBe(5);
  });
  it("should return the sum of two numbers (one is negative)", () => {
    expect(sum(-1, 2)).toBe(1);
  });
});

Pourquoi la couverture est-elle importante ?

• Identifier les lacunes dans les tests : les rapports de couverture mettent en évidence les parties de votre code qui ne sont pas testées. Cela vous aide à garantir que la logique critique n’est pas négligée.
• Amélioration de la qualité du code : une couverture élevée garantit que les cas extrêmes, la gestion des erreurs et la logique métier sont testés de manière approfondie, réduisant ainsi le risque de bogues.
• Confiance dans le refactoring : si vous disposez d'une base de code bien testée, vous pouvez refactoriser en toute confiance, sachant que vos tests détecteront les régressions.
• Meilleure maintenance : une base de code avec une couverture de tests élevée est plus facile à maintenir, car vous pouvez détecter des changements involontaires ou des effets secondaires lors des mises à jour.
• Prend en charge TDD : pour les développeurs pratiquant le développement piloté par les tests, la couverture de surveillance garantit que les tests s'alignent sur la mise en œuvre.

Équilibrer les objectifs de couverture

Bien qu'une couverture de test élevée soit importante, ce n'est pas la seule mesure de la qualité du code. Visez des tests significatifs axés sur les fonctionnalités, les cas extrêmes et les parties critiques de votre application. Atteindre une couverture à 100 % est idéal, mais pas au prix de la rédaction de tests inutiles ou triviaux.

Conclusion

Le développement piloté par les tests (TDD) avec Bun Test permet aux développeurs d'écrire du code propre, maintenable et robuste en se concentrant d'abord sur les exigences et en garantissant la fonctionnalité grâce à des tests itératifs. En tirant parti des outils de test rapides et efficaces de Bun, vous pouvez rationaliser votre processus de développement et gérer en toute confiance les cas extrêmes. L'adoption de TDD améliore non seulement la qualité du code, mais favorise également un état d'esprit consistant à écrire du code modulaire et testable dès le départ. Commencez petit, répétez souvent et laissez vos tests guider votre mise en œuvre.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!