Cas pratiques TDD

Contexte Un test TDD a été écrit pour une fonction countLetters(str) qui doit retourner le nombre de caractères d’une chaîne. Le Problème Le code actuel : function countLetters(str) { return 0; } test("countLetters retourne la longueur", () => { expect(countLetters("abc")).toBe(3); }); La fonction ne respecte pas le test. Contraintes Modifier uniquement l’implémentation pour faire passer le test. Livrable attendu Une version fonctionnelle respectant le test existant dans l’esprit TDD.

Contexte Un test TDD a été écrit pour une fonction reverseString(str) qui doit inverser une chaîne. Le Problème Le code actuel : function reverseString(str) { return str; } test("reverseString inverse la chaîne", () => { expect(reverseString("abc")).toBe("cba"); }); La fonction ne respecte pas le test. Contraintes Modifier uniquement l’implémentation afin de satisfaire le test existant. Livrable attendu Une fonction correcte respectant la logique attendue dans un cycle TDD.

Contexte Un test TDD vérifie qu’une fonction divide(a, b) retourne le résultat de la division. Le Problème Le code actuel : function divide(a, b) { return 0; } test("divide retourne le quotient", () => { expect(divide(10, 2)).toBe(5); }); La fonction ne respecte pas le test. Contraintes Modifier uniquement l’implémentation pour satisfaire le test. Livrable attendu Une version correcte respectant le comportement attendu dans le cycle TDD.

Contexte Un test TDD vérifie qu’une fonction max(a, b) retourne le plus grand des deux nombres. Le Problème Le code actuel : function max(a, b) { return a; } test("max retourne le plus grand nombre", () => { expect(max(2, 5)).toBe(5); }); L’implémentation ne satisfait pas le test. Contraintes Corriger la fonction sans modifier le test. Livrable attendu Une implémentation correcte respectant le principe Green du cycle TDD.

Contexte En approche TDD, un premier test a été écrit pour une fonction sum(a, b) qui doit retourner la somme de deux nombres. L’implémentation actuelle est volontairement minimale. Le Problème Le code suivant ne satisfait pas le test : function sum(a, b) { return a; } test("sum retourne la somme de deux nombres", () => { expect(sum(2, 3)).toBe(5); }); L’implémentation ne respecte pas le comportement attendu. Contraintes Modifier uniquement la fonction pour faire passer le test en respectant la logique métier simple. Livrable attendu Une implémentation correcte permettant au test existant de réussir dans une démarche TDD.

Contexte En TDD, vous devez développer une fonction greet(name) qui retourne "Bonjour, <name>". Le Problème La fonction n’existe pas encore. Il faut commencer par définir le comportement attendu. Contraintes Écrire des tests couvrant un nom standard et une chaîne vide. Les tests doivent être simples et explicites. Livrable attendu Une suite de tests servant de base au cycle Red-Green-Refactor.

Contexte En approche TDD, vous devez implémenter une fonction removeSpaces(str) qui supprime tous les espaces d’une chaîne. Le Problème Aucun test n’a encore été écrit pour décrire le comportement attendu. Contraintes Rédiger des tests couvrant une chaîne avec espaces internes, une chaîne sans espace et une chaîne vide. Livrable attendu Une suite de tests unitaires décrivant précisément le comportement attendu avant implémentation.

Contexte Vous démarrez un développement en TDD pour une fonction isEven(number) qui retourne true si le nombre est pair. Le Problème Aucun test n’existe encore. Il faut commencer par écrire les tests avant toute implémentation. Contraintes Rédiger au minimum trois tests : un nombre pair, un nombre impair et zéro. Les tests doivent être simples et explicites. Livrable attendu Une première suite de tests unitaires servant de base au cycle Red-Green-Refactor.

Contexte Vous devez développer en TDD une fonction capitalize(str) qui met en majuscule la première lettre d’une chaîne. Le Problème La fonction n’existe pas encore. Il faut définir les tests décrivant le comportement attendu. Contraintes Créer des tests couvrant une chaîne normale, une chaîne vide et une chaîne déjà capitalisée. Livrable attendu Une suite de tests claire permettant ensuite d’implémenter la fonction dans un cycle TDD.

Contexte Vous démarrez un développement en TDD pour une fonction contains(array, value) qui retourne true si la valeur est présente. Le Problème Il faut définir les tests avant d’écrire l’implémentation. Contraintes Créer des tests pour un tableau contenant la valeur, ne la contenant pas et un tableau vide. Livrable attendu Une suite de tests décrivant clairement le comportement attendu dans une démarche TDD.

Contexte Des tests TDD définissent qu’une fonction fetchUser(id) retourne une promesse résolue avec un objet utilisateur. Le Problème Le code actuel : function fetchUser(id) { return { id: id }; } test("retourne une promesse", async () => { const user = await fetchUser(1); expect(user.id).toBe(1); }); Contraintes Adapter l’implémentation pour respecter le contrat asynchrone sans modifier les tests. Livrable attendu Une version conforme au comportement attendu dans une approche TDD.

Contexte Dans une démarche TDD, des tests ont été écrits pour une fonction calculateDiscount(price, percentage) qui applique une remise en pourcentage. Le Problème L’implémentation actuelle ne satisfait pas les tests : function calculateDiscount(price, percentage) { return price - percentage; } test("applique une remise de 10%", () => { expect(calculateDiscount(100, 10)).toBe(90); }); test("aucune remise si pourcentage 0", () => { expect(calculateDiscount(100, 0)).toBe(100); }); Contraintes Modifier uniquement l’implémentation pour faire passer les tests existants. Livrable attendu Une version correcte respectant le cycle Red-Green-Refactor.

Contexte Des tests TDD définissent qu’une fonction divide(a, b) doit lever une erreur si b vaut 0. Le Problème Le code actuel : function divide(a, b) { return a / b; } test("lève une erreur si division par zéro", () => { expect(() => divide(10, 0)).toThrow(); }); Contraintes Adapter uniquement l’implémentation pour satisfaire le test sans modifier celui-ci. Livrable attendu Une fonction respectant les tests et le cycle Green du TDD.

Contexte En TDD, des tests définissent le comportement d’un objet Cart avec méthodes addItem(price) et getTotal(). Le Problème Le code actuel : class Cart { constructor() { this.total = 0; } addItem(price) { this.total = price; } getTotal() { return this.total; } } test("ajoute deux articles", () => { const cart = new Cart(); cart.addItem(10); cart.addItem(5); expect(cart.getTotal()).toBe(15); }); Contraintes Modifier uniquement l’implémentation pour satisfaire les tests existants. Livrable attendu Une classe conforme aux tests dans l’esprit TDD.

Contexte Des tests TDD définissent qu’une fonction filterActive(users) retourne uniquement les utilisateurs avec active: true. Le Problème Le code actuel : function filterActive(users) { return users; } test("retourne uniquement les utilisateurs actifs", () => { const users = [ { name: "A", active: true }, { name: "B", active: false } ]; expect(filterActive(users)).toEqual([ { name: "A", active: true } ]); }); Contraintes Modifier uniquement la fonction pour satisfaire le test. Livrable attendu Une implémentation correcte respectant les tests existants.

Contexte Vous devez développer en TDD une fonction convert(amount, rate) qui multiplie un montant par un taux. Le Problème La fonction n’est pas encore écrite. Il faut commencer par définir les comportements attendus. Contraintes Créer des tests couvrant taux standard, taux zéro et montants décimaux. Les assertions doivent vérifier la précision des résultats. Livrable attendu Une suite de tests servant de base au cycle Red-Green-Refactor.

Contexte Vous développez en TDD une fonction validatePassword(password) avec plusieurs règles : longueur minimale 8 caractères, au moins un chiffre, au moins une majuscule. Le Problème La fonction n’existe pas encore. Il faut d’abord écrire les tests décrivant chaque règle. Contraintes Créer des tests couvrant les cas valides, invalides partiels et totalement invalides. Chaque règle doit être testée indépendamment. Livrable attendu Une suite de tests structurée permettant ensuite l’implémentation incrémentale selon le cycle TDD.

Contexte Vous développez en TDD une classe Queue avec méthodes enqueue(value) et dequeue(). Le Problème Il faut écrire les tests décrivant le comportement FIFO avant toute implémentation. Contraintes Créer des tests couvrant l’ajout multiple, la suppression dans l’ordre d’insertion et le comportement sur file vide. Livrable attendu Une suite de tests claire permettant une implémentation progressive en respectant le cycle TDD.

Contexte Vous devez implémenter en TDD une fonction calculateTax(income) appliquant différents taux selon des tranches. Le Problème Aucun test n’existe. Il faut définir les règles métier à travers les tests. Contraintes Créer des tests couvrant plusieurs tranches, y compris les limites exactes. Vérifier les montants retournés pour différents revenus. Livrable attendu Une suite de tests structurée décrivant clairement les règles avant implémentation.

Contexte Vous devez développer en TDD une fonction groupByCategory(items) qui regroupe des objets par propriété category. Le Problème Aucun test n’existe encore. Il faut définir les comportements attendus. Contraintes Créer des tests couvrant : tableau vide, plusieurs catégories différentes, et plusieurs éléments dans une même catégorie. Vérifier la structure exacte de l’objet retourné. Livrable attendu Une suite de tests décrivant précisément la structure de sortie avant implémentation.

Contexte Des tests TDD définissent qu’un Cache doit stocker une valeur avec un TTL et l’invalider après expiration. Le Problème Le code actuel : class Cache { constructor() { this.store = {}; } set(key, value) { this.store[key] = value; } get(key) { return this.store[key]; } } Un test exige que la valeur expire après un délai simulé. Contraintes Adapter l’implémentation pour respecter les tests sans modifier ceux-ci. Livrable attendu Une classe conforme aux exigences d’expiration définies par les tests.

Contexte Des tests TDD définissent qu’une AsyncQueue traite les tâches dans l’ordre tout en respectant une limite de concurrence. Le Problème Le code actuel : class AsyncQueue { constructor() { this.tasks = []; } add(task) { this.tasks.push(task); task(); } } Un test exige qu’au maximum deux tâches s’exécutent simultanément. Contraintes Adapter uniquement l’implémentation pour satisfaire les tests existants. Livrable attendu Une classe conforme aux exigences de concurrence définies par les tests.

Contexte Des tests TDD définissent le comportement d’un OrderService qui doit réserver un stock, débiter un paiement et confirmer la commande de manière atomique. Le Problème L’implémentation actuelle ne gère pas correctement les échecs intermédiaires : class OrderService { constructor(stock, payment) { this.stock = stock; this.payment = payment; } async place(order) { await this.stock.reserve(order); await this.payment.charge(order); return "confirmed"; } } Un test exige que si payment.charge échoue, le stock soit libéré. Contraintes Modifier uniquement l’implémentation pour satisfaire les tests existants sans les altérer. Livrable attendu Une version conforme aux tests garantissant la cohérence transactionnelle.

Contexte Des tests TDD définissent qu’une fonction parseConfig(json) valide la structure et lève une erreur si un champ obligatoire manque. Le Problème Le code actuel : function parseConfig(json) { return JSON.parse(json); } Un test exige une validation stricte des champs requis. Contraintes Modifier uniquement l’implémentation pour satisfaire les tests existants. Livrable attendu Une fonction conforme aux tests contractuels et aux règles définies.

Contexte Des tests TDD définissent qu’une fonction validate(data) applique plusieurs validateurs en chaîne et s’arrête au premier échec. Le Problème Le code actuel : function validate(data, validators) { validators.forEach(v => v(data)); return true; } Un test exige que la fonction retourne false immédiatement si un validateur échoue. Contraintes Modifier uniquement l’implémentation pour satisfaire les tests existants. Livrable attendu Une version respectant la logique d’arrêt anticipé définie par les tests.

Contexte Vous devez développer en TDD un DataAggregator qui interroge plusieurs services asynchrones et combine leurs résultats. Le Problème Le composant doit continuer à fonctionner même si un service échoue. Contraintes Créer des tests couvrant succès complet, échec partiel et latence simulée. Vérifier que les résultats valides sont conservés et que les erreurs sont gérées. Livrable attendu Une suite de tests robuste décrivant la résilience attendue avant implémentation.

Contexte Vous devez implémenter en TDD un RuleEngine appliquant dynamiquement une liste de règles à une entrée donnée. Le Problème Aucun test n’existe encore. Le moteur doit appliquer les règles dans l’ordre et retourner une décision finale. Contraintes Créer des tests couvrant : aucune règle, une règle valide, plusieurs règles combinées et règle générant une erreur. Vérifier l’ordre d’exécution et le résultat final. Livrable attendu Une suite de tests décrivant précisément le comportement attendu avant implémentation.

Contexte Vous devez développer en TDD un PricingEngine appliquant des règles conditionnelles selon le profil client. Le Problème Le moteur doit appliquer des remises cumulatives ou exclusives selon des conditions. Contraintes Créer des tests couvrant client standard, client premium et règles conflictuelles. Vérifier le calcul final et l’ordre d’application. Livrable attendu Une suite de tests exhaustive décrivant le comportement attendu avant implémentation.

Contexte Vous devez implémenter en TDD un EventDispatcher permettant l’enregistrement de listeners avec option stopPropagation. Le Problème Les listeners doivent s’exécuter dans l’ordre d’enregistrement sauf si l’un stoppe la propagation. Contraintes Créer des tests couvrant exécution complète, arrêt anticipé et absence de listeners. Vérifier l’ordre d’appel et les effets attendus. Livrable attendu Une suite de tests précise décrivant le comportement avant toute implémentation.

Contexte Vous devez implémenter en TDD un PermissionService gérant des rôles hiérarchiques avec héritage de droits. Le Problème Les rôles supérieurs doivent automatiquement inclure les permissions des rôles inférieurs. Contraintes Créer des tests couvrant rôle simple, rôle hérité et combinaison de permissions multiples. Vérifier explicitement les droits accordés et refusés. Livrable attendu Une suite de tests détaillant précisément la logique d’héritage avant implémentation.