Lab 2.2 : Construction du Filet de Sécurité

Module : 2.2 - Génération de Tests | ← SlidesDurée : 1 heure Projet d'exemple : node-express-mongoose-demo

Objectifs d'Apprentissage

À la fin de ce lab, vous serez capable de :

• Générer des tests unitaires pour des fonctions non testées
• Créer des tests de cas limites (null, vide, conditions aux limites)
• Exécuter les tests et vérifier qu'ils passent
• Construire un filet de sécurité avant de refactoriser

Prérequis

• Lab 2.1 (Mode Plan) complété
• Compréhension du framework de test utilisé dans le projet

Pourquoi les Tests sont Importants

La Règle d'Or

« Vous ne pouvez pas refactoriser du code en toute sécurité s'il n'a pas de tests. »

Les tests sont votre harnais de sécurité :

• Ils prouvent que le code fonctionne avant de le modifier
• Ils détectent les régressions pendant le refactoring
• Ils documentent le comportement attendu

Configuration

# Naviguer vers le projet d'exemple
cd sample-projects/node-express-mongoose-demo

# Installer les dépendances (si ce n'est pas fait)
npm install

# Vérifier que les tests s'exécutent
npm test

# Démarrer Claude Code
claude

---

Tâche 1 : Trouver le Code Non Testé

Durée : 10 minutes

Identifier les fonctions qui nécessitent une couverture de tests.

Prompts à essayer :

What functions in this project have no tests?

Show me functions in app/controllers that aren't covered by tests.

Which critical functions lack test coverage?

Choisir une cible : Sélectionnez une fonction qui :

• Est utilisée à plusieurs endroits (impact élevé)
• N'a pas de tests existants
• A des entrées et sorties claires

Critères de réussite :

• [ ] 2-3 fonctions non testées identifiées
• [ ] Une fonction critique sélectionnée pour les tests

---

Tâche 2 : Générer des Tests de Base

Durée : 15 minutes

Créer un fichier de test pour la fonction choisie.

Prompts à essayer :

Generate a test file for the create function in app/controllers/articles.js. Use the project's existing test framework.

Write unit tests for the User model's authenticate method.

Examiner le résultat :

• Est-ce que le chemin nominal (happy path) est testé ?
• Est-ce que le bon framework de test est utilisé ?
• Les assertions sont-elles significatives ?

Critères de réussite :

• [ ] Fichier de test généré
• [ ] Les tests s'exécutent sans erreurs
• [ ] Le chemin nominal est couvert

---

Tâche 3 : Ajouter des Tests de Cas Limites

Durée : 20 minutes

Étendre la couverture avec des cas limites.

Prompts à essayer :

Add edge case tests for:
- null or undefined inputs
- empty strings or arrays
- boundary conditions
- invalid data types

What edge cases should we test for the validateUser function?

Add tests for error scenarios in the article controller.

Cas limites courants à tester :

Catégorie	Exemples
Null/undefined	null, undefined, paramètres manquants
Vide	"", [], {}
Limites	0, -1, MAX_INT, chaînes très longues
Types	Mauvais type (string au lieu de number)
État	Non connecté, session expirée

Critères de réussite :

• [ ] Au moins 3 tests de cas limites ajoutés
• [ ] Les tests gèrent les scénarios d'erreur
• [ ] Tous les tests passent

---

Tâche 4 : Exécuter et Vérifier

Durée : 15 minutes

S'assurer que tous les tests passent et que la couverture s'est améliorée.

# Exécuter la suite de tests
npm test

# Si un rapport de couverture est disponible
npm run test:coverage

Checklist de vérification :

• [ ] Tous les nouveaux tests passent
• [ ] Les tests existants passent toujours
• [ ] Pas de faux positifs (tests qui passent toujours)

Déboguer les tests échoués :

This test is failing. Can you explain why and fix it?

Critères de réussite :

• [ ] Tous les tests passent
• [ ] Comprendre ce que chaque test vérifie

---

Checklist de Qualité des Tests

Les bons tests doivent être :

• [ ] Isolés - Chaque test peut s'exécuter indépendamment
• [ ] Déterministes - Même résultat à chaque fois
• [ ] Lisibles - Clair sur ce qui est testé
• [ ] Rapides - S'exécutent en millisecondes, pas en secondes
• [ ] Significatifs - Tester le comportement, pas l'implémentation

---

Exemple de Structure de Test

describe('ArticleController', () => {
  describe('create', () => {
    it('should create article with valid data', async () => {
      // Arrange
      const articleData = { title: 'Test', body: 'Content' };

      // Act
      const result = await controller.create(articleData);

      // Assert
      expect(result).toHaveProperty('id');
      expect(result.title).toBe('Test');
    });

    it('should throw error with missing title', async () => {
      // Arrange
      const articleData = { body: 'Content' };

      // Act & Assert
      await expect(controller.create(articleData))
        .rejects.toThrow('Title is required');
    });

    it('should handle null input', async () => {
      await expect(controller.create(null))
        .rejects.toThrow();
    });
  });
});

---

Conseils pour Réussir

1. Correspondre au style du projet - Regardez les tests existants pour les patterns
2. Tester le comportement, pas l'implémentation - Se concentrer sur le quoi, pas le comment
3. Une assertion par test - Plus facile à déboguer quand ça échoue
4. Utiliser des noms descriptifs - "should return error when email is invalid"

---

Dépannage

Les tests ne s'exécutent pas

• Vérifier que le framework de test est installé
• Vérifier la convention de nommage des fichiers de test
• Vérifier le script de test dans package.json

Les tests échouent de manière inattendue

• Lire attentivement le message d'erreur
• Vérifier si du mocking est nécessaire
• Vérifier la configuration de la base de données de test

---

Objectifs Bonus

Si vous finissez en avance :

1. Générer des tests d'intégration pour un endpoint API
2. Ajouter des tests pour la gestion d'erreurs asynchrones
3. Créer un test pour un flux complexe à plusieurs étapes

---

Livrables

À la fin de ce lab, vous devriez avoir :

1. Nouveau(x) fichier(s) de test commité(s) dans le projet
2. Au moins 5 tests (chemin nominal + cas limites)
3. Tous les tests qui passent
4. La confiance pour refactoriser le code testé

---

Prochaines Étapes

Après avoir complété ce lab, passez au Lab 2.3 : Red-Green-Refactor-AI pour pratiquer le TDD avec Claude.