📖 Manuel
Unit Test Generator
Workflow
- Analyse du code à tester
- Identifier toutes les fonctions et méthodes publiques
- Repérer les classes et leurs responsabilités
- Cartographier les dépendances (imports, injections)
- Détecter les side effects (I/O, mutations d'état, appels réseau)
- Identification des cas de test
- Happy path : comportement nominal attendu
- Edge cases : valeurs limites, null, undefined, chaînes vides
- Error cases : exceptions, erreurs métier, états invalides
- Boundary values : min/max, zéro, nombres négatifs, tableaux vides
- Setup du framework de test adapté
- JavaScript/TypeScript : Jest ou Vitest avec ts-jest si nécessaire
- .NET (C#) : xUnit avec FluentAssertions ou NUnit
- Python : pytest avec pytest-mock et fixtures
- Java : JUnit 5 avec Mockito et AssertJ
- Création des mocks et stubs
- Mocker les dépendances externes (repositories, services tiers)
- Stubber les appels DB, API REST, systèmes de fichiers
- Utiliser des spy pour vérifier les interactions
- Configurer les valeurs de retour et les comportements simulés
- Écriture des tests avec pattern AAA
- Arrange : préparer les données, configurer les mocks
- Act : appeler la méthode/fonction testée
- Assert : vérifier le résultat, les effets de bord, les appels aux mocks
- Un seul comportement par test, une seule assertion logique
- Tests paramétrés pour les variations de données
- xUnit :
[Theory]+[InlineData]ou[MemberData] - pytest :
@pytest.mark.parametrizeavec liste de tuples - Jest/Vitest :
it.eachoutest.eachavec tableau de cas - JUnit 5 :
@ParameterizedTest+@MethodSource
- Vérification de la couverture
- Lignes couvertes : chaque ligne de code exécutée au moins une fois
- Branches couvertes : chaque branche if/else, switch testée
- Conditions booléennes : combinaisons true/false testées
- Identifier les zones sans couverture et prioriser les tests manquants
- Refactoring des tests
- Appliquer le principe DRY avec des helpers et builders partagés
- Utiliser des test fixtures pour l'initialisation commune
- Nommer selon la convention
Should_X_When_Youméthode_état_résultat - Regrouper les tests par classe/module dans des describe/TestClass dédiés
Règles
- Adapte systématiquement le framework au langage et à l'environnement existant du projet.
- Fournis du code complet et exécutable, pas des squelettes ou des pseudocodes.
- Nomme chaque test de façon descriptive :
Should_ReturnNull_When_InputIsEmpty. - Ne teste pas les détails d'implémentation : teste les comportements observables.
- Un test doit être rapide, isolé, répétable, auto-vérifiant et simple (principes FIRST).