Cas pratiques Tests Unitaires

Contexte Une fonction sortNumbers(array) trie un tableau de nombres par ordre croissant. Le Problème L’équipe souhaite s’assurer que le tri fonctionne pour différentes tailles de tableaux. Contraintes Créer des tests couvrant un tableau vide, un tableau déjà trié et un tableau désordonné. Les tests doivent vérifier l’ordre exact des éléments. Livrable attendu Une suite de tests unitaires démontrant que la fonction gère correctement les cas standards et limites.

Contexte Une fonction fetchData() retourne une promesse résolue avec la chaîne "ok". Un test a été écrit mais il réussit même si la valeur change. Le Problème Le test actuel : test("fetchData retourne ok", () => { fetchData().then(data => { expect(data).toBe("ok"); }); }); Ce test ne gère pas correctement l’asynchronisme. Contraintes Vous devez corriger le test pour qu’il attende réellement la résolution de la promesse. Livrable attendu Un test asynchrone corrigé utilisant return ou async/await afin d’assurer une vérification fiable.

Contexte Une équipe développe une petite bibliothèque utilitaire contenant une fonction add(a, b). Un test unitaire a été écrit pour valider son comportement, mais il échoue alors que la fonction semble correcte. Le Problème Le test suivant ne passe pas : function add(a, b) { return a + b; } test("addition de deux nombres", () => { expect(add(2, 3)).toBe("5"); }); Le test compare le résultat avec une valeur incorrecte. Contraintes Vous ne devez pas modifier la logique métier si elle est correcte. Vous devez corriger uniquement le test pour qu’il reflète le comportement attendu. Livrable attendu Une version corrigée du test unitaire garantissant que la fonction add retourne bien un nombre égal à 5.

Contexte Une variable globale est utilisée dans plusieurs tests. Le Problème Le code suivant provoque des effets de bord : let total = 0; function increment() { total++; } test("incrémente une fois", () => { increment(); expect(total).toBe(1); }); test("incrémente encore", () => { increment(); expect(total).toBe(1); }); Le second test échoue. Contraintes Garantir l’isolation des tests. Livrable attendu Une version corrigée assurant que chaque test démarre avec un état propre.

Contexte Une suite de tests initialise une variable compteur avant chaque test. Le Problème Le code actuel : let counter = 0; beforeEach(() => { counter + 1; }); test("counter vaut 1", () => { expect(counter).toBe(1); }); Le compteur ne s’incrémente jamais. Contraintes Corriger uniquement la configuration du test sans modifier la structure globale. Livrable attendu Une version fonctionnelle garantissant que counter est bien réinitialisé et incrémenté correctement avant chaque test.

Contexte Une fonction isAdult(age) retourne true si l’âge est supérieur ou égal à 18. Le Problème Le test actuel : function isAdult(age) { return age >= 18; } test("age 18 est adulte", () => { expect(isAdult(18)).toBe(false); }); Le test contient une mauvaise attente. Contraintes Ne pas modifier la fonction métier si elle est correcte. Livrable attendu Une version corrigée du test reflétant la logique réelle de la fonction.

Contexte Une fonction calculateVAT(price, rate) applique un taux de TVA à un prix donné. Le Problème La fonction est utilisée en production mais aucun test n’existe pour vérifier la justesse des calculs. Contraintes Écrire au moins trois tests : un cas standard, un cas avec taux zéro, et un cas avec prix décimal. Les assertions doivent vérifier la précision du résultat. Livrable attendu Une suite de tests unitaires clairs et lisibles garantissant que la fonction retourne le montant TTC correct.

Contexte Une fonction removeItem(list, item) supprime un élément d’un tableau. Le Problème Il faut vérifier que la suppression fonctionne correctement et ne modifie pas les autres éléments. Contraintes Tester la suppression d’un élément existant, d’un élément inexistant et dans un tableau vide. Livrable attendu Une suite de tests unitaires validant que la fonction retourne le tableau attendu dans chaque scénario.

Contexte Une fonction validateEmail(email) retourne true si l’email contient "@" et ".", sinon false. Aucun test unitaire n’a encore été écrit. Le Problème L’équipe souhaite sécuriser ce comportement avec des tests simples couvrant les cas valides et invalides. Contraintes Les tests doivent couvrir au minimum trois cas : un email valide standard, un email sans "@", et un email sans domaine. Les tests doivent être indépendants et clairs. Livrable attendu Une suite de tests unitaires simples vérifiant que validateEmail retourne les bonnes valeurs selon les entrées fournies.

Contexte Une fonction toUpperCase(str) convertit une chaîne en majuscules. Le Problème Il est nécessaire de garantir son bon fonctionnement sur différents types d’entrées. Contraintes Tester une chaîne normale, une chaîne vide et une chaîne contenant des caractères spéciaux. Les tests doivent être indépendants. Livrable attendu Une suite de tests unitaires validant que la conversion en majuscules fonctionne correctement pour tous les cas simples.

Contexte Un service CartService permet d’ajouter, supprimer et calculer le total d’articles dans un panier. Le Problème Il faut garantir que le total est correct après plusieurs opérations successives. Contraintes Écrire des tests couvrant : ajout multiple, suppression partielle, panier vide, et calcul avec prix décimaux. Les tests doivent vérifier l’état interne et le total retourné. Livrable attendu Une suite complète de tests unitaires validant le comportement métier du service.

Contexte Une fonction async login(user) rejette une promesse si les identifiants sont invalides. Le Problème Le test suivant ne détecte pas correctement l’erreur : test("login invalide rejette", async () => { await login({ username: "x", password: "y" }); expect(true).toBe(false); }); Le test réussit parfois alors qu’il devrait échouer. Contraintes Corriger le test pour vérifier explicitement le rejet de promesse. Livrable attendu Un test fiable utilisant rejects ou try/catch pour valider l’erreur attendue.

Contexte Une fonction isExpired(date) compare une date fournie avec la date actuelle. Le Problème Le test suivant échoue selon le jour d’exécution : function isExpired(date) { return new Date() > new Date(date); } test("date passée est expirée", () => { expect(isExpired("2023-01-01")).toBe(true); }); Le test dépend de l’horloge système. Contraintes Rendre le test déterministe en mockant la date actuelle. Livrable attendu Une version stable du test garantissant un résultat constant.

Contexte Une fonction createUser retourne un objet utilisateur. Le Problème Le test suivant échoue : function createUser(name) { return { id: 1, name: name }; } test("retourne utilisateur", () => { expect(createUser("Bob")).toBe({ id: 1, name: "Bob" }); }); La comparaison d’objets ne fonctionne pas avec toBe. Contraintes Corriger l’assertion sans modifier la fonction. Livrable attendu Un test utilisant la bonne méthode d’assertion pour comparer des objets.

Contexte Une base de données simulée est partagée entre plusieurs tests. Le Problème Le code actuel : let db = []; function add(item) { db.push(item); } test("ajoute un élément", () => { add("A"); expect(db.length).toBe(1); }); test("db vide au départ", () => { expect(db.length).toBe(0); }); Le second test échoue. Contraintes Garantir l’isolation via une réinitialisation appropriée. Livrable attendu Une version corrigée utilisant beforeEach ou afterEach pour nettoyer l’état.

Contexte Une fonction getUserProfile(id) dépend d’un service externe fetchUser(id). Pour tester la logique interne, un mock est utilisé. Le Problème Le test suivant échoue de manière imprévisible : const fetchUser = jest.fn(); function getUserProfile(id) { return fetchUser(id).name; } test("retourne le nom utilisateur", () => { fetchUser.mockReturnValue({ name: "Alice" }); const result = getUserProfile(1); expect(result).toBe("Alice"); }); La fonction ne gère pas correctement la valeur retournée. Contraintes Corriger soit l’implémentation soit le test afin d’assurer un comportement cohérent. Livrable attendu Une version corrigée garantissant un test fiable et isolé.

Contexte Un contrôleur createUser(req, res) appelle un service externe userService.save(). Le Problème Il faut tester que le contrôleur retourne le bon code HTTP selon le résultat du service. Contraintes Mocker le service pour simuler succès et erreur. Vérifier que res.status et res.json sont appelés correctement. Livrable attendu Une suite de tests unitaires isolant le contrôleur de ses dépendances.

Contexte Une fonction withdraw(amount) lève une erreur personnalisée si le solde est insuffisant. Le Problème Il faut tester que l’exception est bien levée et contient le bon message. Contraintes Créer des tests vérifiant à la fois le type d’erreur et son message. Tester également un cas valide. Livrable attendu Une suite de tests assurant la robustesse du comportement en cas d’erreur métier.

Contexte Une fonction multiply(a, b) doit être testée sur plusieurs combinaisons d’entrées. Le Problème Les tests actuels sont répétitifs et difficiles à maintenir. Contraintes Créer des tests paramétrés couvrant des nombres positifs, négatifs et zéro. Utiliser une approche structurée pour éviter la duplication de code. Livrable attendu Une suite de tests paramétrés claire, lisible et facilement extensible.

Contexte Une fonction validatePassword applique plusieurs règles : longueur minimale, présence d’un chiffre et d’une majuscule. Le Problème Il faut garantir que chaque règle est correctement testée individuellement et en combinaison. Contraintes Créer des tests couvrant les cas valides, invalides partiels et totalement invalides. Les assertions doivent être explicites. Livrable attendu Une suite de tests complète assurant une couverture logique robuste.

Contexte Un DataAggregator interroge plusieurs services externes et agrège les résultats. Le Problème Il faut tester que si un service échoue, les autres continuent et un résultat partiel est renvoyé. Contraintes Mocker plusieurs dépendances avec scénarios de latence et d’erreur. Vérifier que l’agrégation respecte les règles métier. Livrable attendu Une suite de tests avancée validant la résilience, la gestion d’erreur et la cohérence des données retournées.

Contexte Un OrderService orchestre plusieurs dépendances : InventoryService, PaymentService et NotificationService. Le Problème Il faut garantir qu’en cas d’échec du paiement, le stock est restauré et aucune notification n’est envoyée. Contraintes Mocker chaque dépendance. Tester les scénarios succès, échec paiement et échec inventaire. Vérifier les appels et l’ordre d’exécution. Livrable attendu Une suite de tests unitaires robuste validant la logique transactionnelle et les effets de bord.

Contexte Une fonction loadAdapter charge dynamiquement un module selon le type fourni. Le Problème Le test actuel : async function loadAdapter(type) { const adapter = await import(`./adapters/${type}.js`); return adapter.default(); } test("charge adapter mock", async () => { jest.mock("./adapters/paypal.js", () => ({ default: () => "ok" })); const result = await loadAdapter("paypal"); expect(result).toBe("ok"); }); Le mock n’est pas appliqué correctement. Contraintes Corriger la stratégie de mock pour les imports dynamiques. Livrable attendu Un test fonctionnel garantissant le bon chargement du module mocké.

Contexte Un module PaymentService importe un module externe gateway.js contenant une fonction process(). Les tests doivent mocker uniquement process tout en conservant les autres exports. Le Problème Le test actuel : jest.mock("./gateway", () => ({ process: jest.fn() })); const { processRefund } = require("./paymentService"); test("remboursement appelle process", () => { const gateway = require("./gateway"); gateway.process.mockReturnValue(true); expect(processRefund(100)).toBe(true); }); D’autres fonctions du module gateway deviennent undefined. Contraintes Corriger le mock pour conserver les exports originaux sauf process. Livrable attendu Un test correctement isolé utilisant un mock partiel fiable.

Contexte Une fonction debounce(fn, delay) utilise setTimeout pour retarder l’exécution. Le Problème Le test suivant échoue aléatoirement : function debounce(fn, delay) { let timer; return (...args) => { clearTimeout(timer); timer = setTimeout(() => fn(...args), delay); }; } test("appelle la fonction après délai", () => { const mockFn = jest.fn(); const debounced = debounce(mockFn, 1000); debounced(); expect(mockFn).toHaveBeenCalled(); }); Le test ne contrôle pas le temps. Contraintes Utiliser des fake timers pour rendre le test déterministe. Livrable attendu Un test corrigé maîtrisant l’horloge et validant correctement le comportement.

Contexte Un Logger est implémenté comme singleton et conserve un historique interne. Le Problème Le test suivant échoue selon l’ordre d’exécution : class Logger { constructor() { if (!Logger.instance) { this.logs = []; Logger.instance = this; } return Logger.instance; } log(msg) { this.logs.push(msg); } } test("log ajoute une entrée", () => { const logger = new Logger(); logger.log("A"); expect(logger.logs.length).toBe(1); }); L’état persiste entre tests. Contraintes Garantir l’isolation des tests sans modifier profondément l’architecture. Livrable attendu Une solution assurant la réinitialisation correcte du singleton entre chaque test.

Contexte Une classe EventBus permet d’enregistrer des listeners. Le Problème Le test actuel : class EventBus { constructor() { this.listeners = []; } on(fn) { this.listeners.push(fn); } } test("ajoute listener", () => { const bus = new EventBus(); bus.on(() => {}); expect(bus.listeners.length).toBe(1); }); Les tests multiples accumulent des références. Contraintes Assurer un nettoyage approprié après chaque test. Livrable attendu Une version garantissant l’absence d’effets cumulés ou de fuite simulée.

Contexte Un module expose une API interne consommée par plusieurs équipes. Le Problème Il faut s’assurer que les signatures et formats de réponse ne changent pas involontairement. Contraintes Créer des tests contractuels vérifiant structure, types et champs obligatoires. Simuler différentes versions d’entrée. Livrable attendu Une suite de tests protégeant contre les régressions contractuelles et assurant la compatibilité descendante.

Contexte Une fonction normalize(value, min, max) doit toujours retourner un nombre compris entre 0 et 1. Le Problème Les tests actuels couvrent seulement quelques cas fixes. Contraintes Mettre en place des tests de propriété générant plusieurs jeux de données aléatoires afin de vérifier l’invariant mathématique. Tester également les limites extrêmes. Livrable attendu Une suite de tests avancée assurant la robustesse statistique de la fonction.

Contexte Un RuleEngine applique dynamiquement plusieurs règles métiers configurables. Le Problème Il faut garantir que les combinaisons de règles produisent les décisions attendues. Contraintes Créer des scénarios couvrant interactions complexes entre règles. Mock partiellement les dépendances. Vérifier les décisions finales et les logs internes. Livrable attendu Une suite de tests complète validant les différents chemins d’exécution et garantissant la cohérence du moteur.