test

<objective> Générer ou exécuter des tests pour le projet actuel. Cette compétence détecte automatiquement le framework de test en usage, génère des tests complets pour les fichiers source, ou exécute les suites de tests existantes et analyse les défaillances.

Accepte des arguments optionnels :

• Un chemin de fichier : générer des tests pour ce fichier source
• run : exécuter la suite de tests existante et analyser les résultats
• Aucun argument : suggérer quoi tester en fonction des changements récents </objective>

<context> Cette compétence gère la génération et l'exécution de tests sur plusieurs langages et frameworks. Elle s'adapte aux conventions de test que le projet utilise déjà plutôt que d'en imposer de nouvelles. </context>

<quick_start>

<step_1_detect_framework>

Détectez le framework de test et les conventions avant toute autre chose.

Vérifiez ces sources dans l'ordre :

1. package.json (projets Node/JS/TS) :

   • scripts.test pour la commande de test
   • devDependencies pour jest, vitest, mocha, ava, tap, node:test, playwright, cypress
   • Les clés de config jest ou vitest

2. Fichiers de configuration :

   • jest.config.*, vitest.config.*, .mocharc.*, ava.config.*
   • pytest.ini, pyproject.toml (cherchez [tool.pytest]), setup.cfg
   • go.mod (les projets Go utilisent go test par défaut)
   • Cargo.toml (les projets Rust utilisent cargo test)

3. Fichiers de test existants :

   • Scannez les fichiers *.test.*, *.spec.*, *_test.*, test_*.*
   • Lisez 1-2 fichiers de test existants pour comprendre les patterns, les imports, le style d'assertion et la structure
   • Notez la structure des répertoires (tests co-localisés vs __tests__/ vs tests/ vs test/)

4. Enregistrez vos découvertes :

   • Nom et version du framework
   • Convention de nommage des fichiers de test
   • Convention de localisation des fichiers de test
   • Style d'import/require
   • Style d'assertion (expect, assert, chai, etc.)
   • Tout utilitaire personnalisé, fixture ou helper utilisé

</step_1_detect_framework>

<step_2_handle_arguments>

Routez en fonction de l'argument fourni.

• Chemin de fichier donné -> Allez à generate_tests
• "run" donné -> Allez à run_tests
• Aucun argument -> Allez à suggest_tests

</step_2_handle_arguments>

<generate_tests>

Générez des tests pour le fichier source spécifié.

A. Lisez et analysez le fichier source :

• Identifiez toutes les fonctions, classes, méthodes et types exportés/publics
• Comprenez les paramètres, types de retour et effets secondaires de chaque fonction
• Notez les patterns de gestion d'erreur (throws, retourne null, retourne Result, etc.)
• Identifiez les dépendances qui devront être mockées

B. Lisez les fichiers de test existants du projet (minimum 1-2 fichiers) :

• Reprenez exactement leur style d'import
• Reprenez leur structure de blocs describe/it ou test
• Reprenez leurs patterns d'assertion
• Reprenez leur approche de mock/stub
• Utilisez les mêmes utilitaires et helpers de test

C. Générez des tests couvrant :

1. Chemins heureux : Les entrées normales attendues produisent les bonnes sorties
2. Cas limites :
   • Entrées vides (chaîne vide, tableau vide, null, undefined, zéro)
   • Valeurs limites (entiers min/max, très longues chaînes)
   • Collections à un seul élément
3. Gestion d'erreur :
   • Entrées invalides qui doivent lever une exception ou retourner une erreur
   • Paramètres obligatoires manquants
   • Incompatibilités de type (le cas échéant)
4. Comportement asynchrone (si la fonction est asynchrone) :
   • Résolution réussie
   • Cas de rejet/erreur
   • Scénarios de timeout (le cas échéant)
5. Dépendances :
   • Mockez les dépendances externes (APIs, bases de données, système de fichiers)
   • Vérifiez l'interaction correcte avec les dépendances (appelées avec les bons arguments)

D. Placez le fichier de test correctement :

• Suivez la convention existante du projet pour la localisation des fichiers de test
• Utilisez la convention de nommage du projet (.test.ts, .spec.js, _test.go, test_*.py, etc.)

E. Exécutez les tests générés immédiatement pour vérifier qu'ils passent.

• Si les tests échouent, lisez le message d'erreur attentivement
• Corrigez le code de test (pas le code source)
• Relancez jusqu'à ce que tous les tests passent

</generate_tests>

<run_tests>

Exécutez la suite de tests existante et analysez les résultats.

A. Déterminez la commande de test :

• Vérifiez scripts.test dans package.json pour les projets Node
• Utilisez pytest pour les projets Python
• Utilisez go test ./... pour les projets Go
• Utilisez cargo test pour les projets Rust
• Repliez-vous sur le CLI du framework détecté

B. Exécutez les tests :

• Lancez la commande de test
• Capturez la sortie complète incluant les défaillances et erreurs

C. Analysez les résultats :

• Rapportez les totaux passé, échoué, ignoré
• Pour chaque défaillance :
  • Identifiez le nom du test qui échoue et le fichier
  • Montrez l'assertion qui a échoué (attendu vs réel)
  • Lisez le code source pertinent si nécessaire
  • Fournissez un diagnostic spécifique de la raison de l'échec
  • Suggérez un correctif concret (est-ce un bug de test ou un bug source ?)

D. Présentez un résumé :

Résultats des tests : X réussis, Y échoués, Z ignorés

Défaillances :
1. [nom du test] - [diagnostic bref]
   Correctif : [suggestion spécifique]

2. [nom du test] - [diagnostic bref]
   Correctif : [suggestion spécifique]

</run_tests>

<suggest_tests>

Suggérez quoi tester quand aucun argument n'est donné.

A. Vérifiez les changements récents :

• Lancez git diff --name-only HEAD~5 pour trouver les fichiers modifiés récemment
• Lancez git diff --name-only --cached pour les fichiers en staging
• Filtrez les fichiers source (excluez les configs, docs, lockfiles)

B. Vérifiez les lacunes de couverture de test :

• Trouvez les fichiers source qui n'ont pas de fichier de test correspondant
• Priorisez les fichiers modifiés récemment

C. Présentez les suggestions :

Fichiers suggérés à tester (basé sur les changements récents et les lacunes de couverture) :

1. [chemin du fichier] - modifié récemment, aucun fichier de test existe
2. [chemin du fichier] - modifié récemment, les tests existent mais pourraient avoir besoin d'une mise à jour
3. [chemin du fichier] - aucune couverture de test trouvée

Lancez `/test <chemin du fichier>` pour générer des tests pour n'importe lequel de ces fichiers.
Lancez `/test run` pour exécuter la suite de tests existante.

</suggest_tests>

</quick_start>

<critical_rules>

1. REPRENEZ LES PATTERNS EXISTANTS : N'imposez jamais un nouveau style de test. Reprenez toujours ce que le projet fait déjà.
2. LISEZ AVANT D'ÉCRIRE : Lisez toujours les fichiers de test existants avant d'en générer de nouveaux.
3. VÉRIFIEZ LES TESTS GÉNÉRÉS : Exécutez toujours les tests générés. Du code de test non testé est peu fiable.
4. NE MODIFIEZ PAS LE CODE SOURCE : Si les tests générés échouent, corrigez les tests, pas la source. Si la source a un vrai bug, rapportez-le à l'utilisateur.
5. MOCKEZ LES DÉPENDANCES EXTERNES : Ne laissez jamais les tests frapper des APIs réelles, des bases de données ou des systèmes de fichiers sauf si le projet utilise explicitement des tests d'intégration de cette façon.
6. UN FICHIER À LA FOIS : Générez des tests pour un fichier source par invocation. Gardez la portée gérable.
7. UTILISEZ LES DÉPENDANCES DU PROJET : N'utilisez que les librairies de test déjà installées dans le projet. N'ajoutez pas de nouvelles dépendances sans demander.

</critical_rules>

<success_criteria>

Avant de terminer :

• [ ] Le framework de test et les conventions ont été détectés correctement
• [ ] Les tests générés correspondent au style de test existant du projet
• [ ] Tous les tests générés passent quand ils sont exécutés
• [ ] Les tests couvrent les chemins heureux, les cas limites et la gestion d'erreur
• [ ] Le fichier de test est placé au bon endroit avec la bonne convention de nommage
• [ ] Aucun code source n'a été modifié

</success_criteria>