Générer une suite de tests complète à partir de n'importe quelle fonction ou description de fonctionnalité
Why this prompt matters
<p>Incomplete tests are the leading cause of regressions in production. A typical developer writing tests from memory covers 60-70% of edge cases — the remaining 30% is where bugs live. Every missed edge case is a future incident, a 2am page, or a data corruption bug discovered by a customer. Beyond bugs: code without proper tests blocks confident refactoring. You end up with unmaintainable spaghetti because nobody dares touch it. This prompt forces systematic coverage across happy paths, boundaries, failures, and integration points — the same coverage a dedicated QA engineer would produce in several hours, generated in under a minute.</p>
What we use it for
You wrote a function or shipped a feature and need full test coverage before merging. You have the code in front of you but writing tests feels slow — you keep forgetting edge cases and your PR review always comes back with 'what about null input?' or 'does this handle timeout?'
Prompt
Act as a senior software engineer and QA architect with deep expertise in test-driven development. Context: I have a [FUNCTION / FEATURE / MODULE] that I need fully tested. It is written in [PROGRAMMING LANGUAGE] and uses [FRAMEWORK / LIBRARY if any]. Here is the code or description: [PASTE YOUR FUNCTION OR FEATURE DESCRIPTION HERE] Task: Generate a comprehensive test suite for the above. Cover ALL of the following: 1. Happy-path unit tests — the standard inputs that should work correctly 2. Edge case unit tests — boundary values, empty inputs, maximum values, off-by-one scenarios 3. Error/failure scenarios — invalid types, null/undefined, out-of-range values, network failures, timeouts 4. Integration test outlines — how this function/feature interacts with [DEPENDENT SYSTEM / DATABASE / API] 5. Security-relevant tests if applicable — SQL injection, XSS, buffer overflow, authentication bypass Constraints: - Write tests in [TEST FRAMEWORK, e.g. Jest, pytest, JUnit, RSpec, Go testing] - Each test must have a clear, descriptive name following the pattern: should_[expected behavior]_when_[condition] - Do NOT write implementation code — only tests - Group tests into describe blocks by category (happy path, edge cases, errors, integration) - For each test you skip or outline without full code, add a comment explaining why and what it would verify Output Format: - Full, runnable test file with all imports - Section headers as comments (// === HAPPY PATH ===, // === EDGE CASES ===, etc.) - After the test file: a short summary table listing test count per category and estimated code coverage % - Flag any testability issues you see in the original code (e.g. tightly coupled dependencies that need mocking)
Le problème de l'écriture manuelle des tests
Demandez à n'importe quel développeur ce qu'il saute quand il est sous pression de délais, et les tests reviennent à chaque fois. Pas parce que les développeurs ne se soucient pas de la qualité — ils s'en soucient — mais parce qu'écrire des tests complets est fastidieux, répétitif et mentalement épuisant. Il faut penser en opposés : qu'est-ce qui casse cela ? À quoi n'ai-je pas pensé ? La plupart des développeurs dans ce mode manquent 30 à 40 % des edge cases significatifs.
Ce prompt résout ce problème en intégrant la pensée systématique d'un ingénieur QA senior dans un modèle réutilisable.
Ce qui rend ce prompt efficace
Le prompt utilise un cadre de couverture à cinq catégories : happy path, edge cases, erreurs, intégration et sécurité. Chaque catégorie correspond à un mode de défaillance différent en production. La contrainte de nommer les tests en utilisant should_[behavior]_when_[condition] force l'IA à être précise plutôt que de générer des noms vagues comme test_1 ou testFunction_works. L'exigence de signaler les problèmes de testabilité détecte les problèmes architecturaux — comme les dépendances fortement couplées — avant qu'ils ne deviennent une dette technique.
Comment l'utiliser
Collez le prompt dans Claude Sonnet 4.5 (ou GPT-4o). Remplissez les trois champs entre crochets : votre langage de programmation, votre framework de test et la description de la fonction ou fonctionnalité. Pour une fonction, collez le code réel. Pour une fonctionnalité, collez les critères d'acceptation ou une description en anglais simple de ce qu'elle fait.
La sortie est un fichier de test prêt à exécuter ainsi qu'un tableau récapitulatif de couverture. Exécutez-le, vérifiez les tests ébauchés qui nécessitent un développement, et vous obtenez une suite de tests de base en quelques minutes plutôt qu'en heures.
Adaptation pour différents langages et frameworks
Le prompt fonctionne aussi bien dans tous les écosystèmes. Pour Python, spécifiez pytest comme framework. Pour TypeScript, utilisez Jest ou Vitest. Pour Java, utilisez JUnit 5. Pour Go, dites simplement Go testing package. La structure de sortie s'adapte en conséquence — l'IA connaît les idiomes de chaque framework et utilisera le style d'assertion, les motifs de mock et l'organisation de fichiers corrects.
Aperçu de sortie exemple
Pour une fonction calculateDiscount(price, memberTier) en TypeScript avec Jest, le prompt génère environ 18 à 24 tests couvrant : les combinaisons standard prix/niveau d'adhésion, les entrées de prix zéro, les prix négatifs, les chaînes de niveau invalides, les paramètres nuls, les cas limites de virgule flottante et le contrat d'intégration avec le service de tarification. Le tableau récapitulatif montre une couverture de ligne estimée au-dessus de 90 %.