Génération de tests PHPUnit
Processus
- Lire le fichier cible pour comprendre la logique
- Identifier le type de test adapté (unitaire ou fonctionnel)
- Analyser les conventions du projet (structure tests/, nommage, base classes)
- Générer le test complet
Conventions à détecter
Avant de générer, inspecter le dossier tests/ pour identifier :
- Structure :
tests/Unit/, tests/Functional/, tests/Integration/, ou autre
- Base class utilisée :
TestCase, KernelTestCase, WebTestCase, custom
- Nommage des méthodes :
test_snake_case(), testCamelCase(), ou attribut #[Test]
- Utilisation de data providers :
#[DataProvider('providerName')]
- Setup/Teardown patterns du projet
Règles
Tests unitaires (classes Domain, ValueObjects, Services sans dépendance externe)
- Placer dans
tests/Unit/ en miroir de la structure src/
- Aucune dépendance au kernel Symfony
- Mocker les interfaces, pas les classes concrètes
- Couvrir :
- Le cas nominal (happy path)
- Au moins un cas limite (null, vide, valeur extrême)
- Au moins un cas d'erreur (exception attendue)
Tests fonctionnels (contrôleurs, commandes, intégration)
- Placer dans
tests/Functional/ ou tests/Integration/
- Ne jamais mocker la base de données
- Utiliser les fixtures du projet si elles existent
- Tester les codes de réponse HTTP, le contenu, les redirections
Data providers
Utiliser un data provider quand :
- Plus de 2 cas testent la même méthode avec des entrées différentes
- Les cas limites sont nombreux (validation, parsing, conversion)
Format :
#[DataProvider('exampleProvider')]
public function test_example(string $input, string $expected): void
{
// ...
}
public static function exampleProvider(): iterable
{
yield 'cas nominal' => ['input', 'expected'];
yield 'cas limite' => ['', ''];
}
Assertions
- Préférer les assertions spécifiques (
assertSame > assertEquals > assertTrue)
- Un test = un comportement. Pas 15 assertions dans un seul test.
- Nommer les tests de manière descriptive :
test_create_user_with_invalid_email_throws_exception
Format de sortie
Générer le fichier de test complet, prêt à exécuter. Inclure les imports, la classe, et toutes les méthodes de test.
1---2name: test3description: Génère des tests PHPUnit pour un fichier ou une classe PHP/Symfony. Couvre le cas nominal, les cas limites et les cas d'erreur. Respecte les conventions du projet (Unit/Functional, data providers, pas de mock DB en fonctionnel). Utiliser quand un développeur veut des tests pour du code existant ou nouveau.4---56# Génération de tests PHPUnit78## Processus9101. Lire le fichier cible pour comprendre la logique112. Identifier le type de test adapté (unitaire ou fonctionnel)123. Analyser les conventions du projet (structure tests/, nommage, base classes)134. Générer le test complet1415## Conventions à détecter1617Avant de générer, inspecter le dossier `tests/` pour identifier :1819- Structure : `tests/Unit/`, `tests/Functional/`, `tests/Integration/`, ou autre20- Base class utilisée : `TestCase`, `KernelTestCase`, `WebTestCase`, custom21- Nommage des méthodes : `test_snake_case()`, `testCamelCase()`, ou attribut `#[Test]`22- Utilisation de data providers : `#[DataProvider('providerName')]`23- Setup/Teardown patterns du projet2425## Règles2627### Tests unitaires (classes Domain, ValueObjects, Services sans dépendance externe)2829- Placer dans `tests/Unit/` en miroir de la structure `src/`30- Aucune dépendance au kernel Symfony31- Mocker les interfaces, pas les classes concrètes32- Couvrir :33 - Le cas nominal (happy path)34 - Au moins un cas limite (null, vide, valeur extrême)35 - Au moins un cas d'erreur (exception attendue)3637### Tests fonctionnels (contrôleurs, commandes, intégration)3839- Placer dans `tests/Functional/` ou `tests/Integration/`40- Ne jamais mocker la base de données41- Utiliser les fixtures du projet si elles existent42- Tester les codes de réponse HTTP, le contenu, les redirections4344### Data providers4546Utiliser un data provider quand :47- Plus de 2 cas testent la même méthode avec des entrées différentes48- Les cas limites sont nombreux (validation, parsing, conversion)4950Format :51```php52#[DataProvider('exampleProvider')]53public function test_example(string $input, string $expected): void54{55 // ...56}5758public static function exampleProvider(): iterable59{60 yield 'cas nominal' => ['input', 'expected'];61 yield 'cas limite' => ['', ''];62}63```6465### Assertions6667- Préférer les assertions spécifiques (`assertSame` > `assertEquals` > `assertTrue`)68- Un test = un comportement. Pas 15 assertions dans un seul test.69- Nommer les tests de manière descriptive : `test_create_user_with_invalid_email_throws_exception`7071## Format de sortie7273Générer le fichier de test complet, prêt à exécuter. Inclure les imports, la classe, et toutes les méthodes de test.