Écrire des tests unitaires complets
Générez une suite de tests unitaires exhaustive couvrant les cas nominaux, les cas limites et les erreurs avec des mocks appropriés.
Coller dans votre IA
Collez ce prompt dans ChatGPT, Claude ou Gemini et personnalisez les variables entre crochets.
Tu es un expert en Test-Driven Development (TDD) et en assurance qualité logicielle. Je dois écrire des tests unitaires complets pour le code suivant écrit en [LANGAGE] avec le framework de test [EX: Jest, Pytest, JUnit] :
[COLLER_LE_CODE_À_TESTER]
Contexte :
- Framework de test : [EX: Jest avec TypeScript, Pytest, JUnit 5]
- Librairie de mock : [EX: jest.mock, unittest.mock, Mockito]
- Couverture cible : [EX: 90% minimum]
- Style de test : [EX: BDD avec describe/it, ou AAA (Arrange-Act-Assert)]
Génère une suite de tests complète qui couvre :
- Cas nominaux : les scénarios d'usage normal où tout fonctionne comme prévu.
- Cas limites : valeurs nulles, chaînes vides, tableaux vides, nombres négatifs, valeurs maximales.
- Cas d'erreur : exceptions attendues, erreurs réseau, timeouts, données malformées.
- Mocks et stubs : mock des dépendances externes (base de données, APIs, services tiers) avec des implémentations réalistes.
- Tests asynchrones : si le code est async, couvre les promesses résolues et rejetées.
Pour chaque test, utilise des noms descriptifs au format 'should [comportement attendu] when [condition]'. Inclus un commentaire expliquant pourquoi chaque cas limite est important à tester.
Personnaliser ce prompt avec Léa
Léa réécrit ce prompt pour ton métier et ton objectif précis — 3 questions suffisent.
Pourquoi ce prompt fonctionne
<p>Ce prompt est efficace car il demande une couverture systématique selon les cinq catégories de tests les plus importantes. En spécifiant le framework et la librairie de mock dès le départ, l'IA produit du code directement utilisable sans nécessiter d'adaptation.</p><p>La convention de nommage imposée ('should [comportement] when [condition]') garantit des tests auto-documentés qui servent également de documentation vivante du comportement attendu du code. C'est une pratique essentielle dans les projets d'équipe.</p><p>La demande de commentaires explicatifs pour les cas limites transforme les tests en outil pédagogique, aidant les développeurs moins expérimentés à comprendre pourquoi certains scénarios doivent être testés, et pas seulement comment.</p>
Cas d'usage
Résultat attendu
Une suite de tests unitaires complète avec cas nominaux, limites, erreurs, mocks et noms descriptifs prêts à l'exécution.
Améliorez ce prompt
Passez ce prompt dans l'Optimiseur pour renforcer le contexte, les contraintes et le format attendu.
Améliore ce prompt avec l'OptimiseurCommentaires
- LéaIA
Pour maximiser l'efficacité, ajoute dans le prompt les valeurs exactes des cas limites (ex: `None, "", -1, 0, sys.maxsize`) et le chemin du module à mocker. Cela évite des tests génériques et assure des assertions précises.
Termes du glossaire
📬 Recevez de nouveaux prompts chaque semaine
Rejoignez notre newsletter et ne manquez aucun prompt.
Pour aller plus loin
Prompts similaires
Rédiger le CLAUDE.md d'un projet : le brief que Claude Code lit à chaque session
Transforme la description de votre projet en CLAUDE.md dense : commandes, structure, conventions, pièges, zones interdites et situations où l'agent doit demander avant d'agir.
Prompt Perplexity pour créer une architecture logicielle
Perplexity se distingue comme un outil particulièrement puissant pour la conception d'architectures logicielles grâce à sa capacité à synthétiser des sources techniques récentes et vérifiées. Contrairement à un LLM classique qui s'appuie uniquement sur ses données d'entraînement, Perplexity interroge le web en temps réel pour intégrer les dernières bonnes pratiques, les patterns architecturaux émergents et les retours d'expérience de la communauté. Que vous conceviez une architecture microservices, un monolithe modulaire ou un système événementiel, un prompt bien structuré permet d'obtenir des recommandations contextualisées avec des sources vérifiables. L'enjeu est de fournir suffisamment de contexte métier et technique pour que Perplexity puisse croiser les informations pertinentes : stack technologique, contraintes de scalabilité, budget d'infrastructure et compétences de l'équipe. En formulant votre demande avec précision, vous transformez Perplexity en véritable architecte consultant capable de proposer des diagrammes de composants, des choix de technologies argumentés et des stratégies de déploiement adaptées à votre contexte spécifique.
Stratégie de backup Kubernetes
Plan de reprise d'activité pour Kubernetes
Adapter une API pour différents clients
Adapter les réponses API selon les besoins du client