ViachaslauStrelnikau/agent-skills

Testeur Java

Modèle opérationnel

Ajoutez des tests qui augmentent la confiance au niveau le plus bas possible de la pyramide de tests. Préférez de nombreux tests unitaires rapides, moins de tests d'intégration ou de contrat, et un très petit nombre de tests de bout en bout pour les parcours critiques.

Commencez par lire le code de production, les tests existants, les fichiers de construction et les conventions CI. Préservez le style de test du projet, sauf s'il est clairement faible ou incohérent. N'introduisez pas une nouvelle bibliothèque de test lorsque le projet dispose déjà d'un équivalent adéquat.

Utilisez Context7 pour obtenir la documentation à jour avant d'ajouter ou de modifier une syntaxe, une configuration, des annotations, des extensions ou des versions de dépendances spécifiques à une bibliothèque pour JUnit, Mockito, AssertJ, Spring Boot Test, Testcontainers, REST Assured, Pact, WireMock, Maven, Gradle ou d'autres outils de test Java. Si Context7 est indisponible ou ne peut pas résoudre la bibliothèque, utilisez la documentation officielle du projet ; ne devinez pas les détails sensibles aux versions.

Sélectionner le mode de tâche

• Pour la mise en œuvre, identifiez le comportement modifié, ajoutez le plus petit ensemble utile de tests et vérifiez-les.
• Pour la révision, inspectez la suite existante et signalez l'exactitude, la couverture des risques manquante, la fragilité, la duplication, les problèmes d'isolement et le coût d'exécution. Ne modifiez pas sauf si l'utilisateur demande des changements.
• Pour le débogage, reproduisez l'échec de manière étroite, classifiez sa cause et modifiez les tests ou le code de production uniquement dans le cadre demandé par l'utilisateur.
• Pour l'organisation ou la planification CI, inventoriez les types de tests, les ensembles de sources, l'exécution, les dépendances et les étapes actuelles du pipeline avant de recommander le placement, la sélection, le parallélisme ou la mise en cache.

Flux de travail

1. Identifiez le comportement à protéger.

   • Trouvez les API publiques, les méthodes de service, les règles métier, les limites de persistance, les gestionnaires de messages, les contrôleurs, les planificateurs et les chemins d'erreur touchés par la demande.
   • Préférez les assertions de comportement aux assertions d'implémentation.
   • Traitez les méthodes privées comme des détails d'implémentation ; testez via le comportement public ou extrayez un collaborateur ciblé si la logique privée est complexe.

2. Choisissez le niveau de test utile le plus bas.

   • Utilisez des tests unitaires pour la logique métier pure, le branchement, la validation, le mappage et l'orchestration des collaborateurs qui peuvent être testés sans E/S réelles.
   • Utilisez des tests de tranche ou d'intégration pour le câblage du framework, les requêtes de persistance, les migrations de données, la sérialisation, les transactions, le routage HTTP, les filtres de sécurité et les adaptateurs de limites externes.
   • Utilisez des tests de contrat lorsqu'une limite de service est détenue par plusieurs équipes ou des déploiements indépendants.
   • Utilisez des tests de bout en bout uniquement pour les flux principaux qui ne peuvent pas être fiables via des tests de niveau inférieur.

3. Mettez en œuvre une couverture ciblée.

   • Couvrez les parcours heureux, les cas limites, les valeurs limites, les entrées invalides, les échecs, les résultats d'autorisation de sécurité, les changements d'état de la base de données et les cas de régression.
   • Utilisez des tests paramétrés pour des exemples d'entrée/sortie répétés.
   • Gardez une seule raison d'échec par test. Nommez les tests par comportement et résultat attendu.
   • Utilisez des données déterministes. Évitez les temps d'attente, les hypothèses de temps réel, l'ordre aléatoire, les dépendances réseau et l'état mutable partagé.

4. Maintenez les tests maintenables.

   • Utilisez de manière cohérente arrange/act/assert ou given/when/then.
   • Créez des builders, des fixtures ou des mères de données de test uniquement lorsque la configuration répétée obscurcit l'intention.
   • Gardez les mocks aux limites des processus ou pour les collaborateurs véritablement difficiles. Ne simulez pas les objets de valeur, les collections ou la logique métier triviale.
   • Évitez de vérifier chaque interaction. Vérifiez d'abord les résultats ; ne vérifiez les interactions que lorsque l'interaction est le comportement.

5. Vérifiez et rapportez.

   • Découvrez les commandes à partir du wrapper, des modules, des plugins, des ensembles de sources et de la configuration CI du dépôt. Lisez references/java-testing-tooling.md pour les règles de construction et de gestion des échecs.
   • Exécutez d'abord la commande de test la plus étroite pertinente, puis la suite plus large si le rayon d'explosion le justifie.
   • Si un test de niveau supérieur expose un bug qu'aucun test de niveau inférieur ne détecte, ajoutez un test de régression de niveau inférieur.
   • Supprimez ou évitez les vérifications de haut niveau dupliquées lorsque les tests de niveau inférieur couvrent déjà les conditions et que le test de haut niveau n'apporte aucune confiance unique.
   • Rapportez les tests ajoutés ou révisés, les comportements couverts, les commandes et les résultats, les échecs ou les vérifications indisponibles, et les risques restants. Distinguez les nouveaux échecs des échecs confirmés préexistants ou environnementaux.

Références

Lisez references/test-pyramid.md pour décider de la portée des tests, du placement CI, de la duplication ou de la quantité de tests de bout en bout à ajouter.

Lisez references/java-testing-tooling.md pour choisir les outils de test Java, les dépendances, les annotations, le style de simulation, la forme de test Spring Boot, les modèles Testcontainers, les tests d'API, les tests de contrat, les commandes de construction ou la classification des échecs.