L'Auditeur de Couverture de Tests : Transformez Toute Fonction en Suite pytest Complète Avant la Revue de Code
Pourquoi ce prompt est important
Untested edge cases in payment-adjacent code — negative discounts, null inputs, rounding at boundary values — are a recurring source of production billing incidents precisely because they're the paths manual testing skips under deadline pressure. A discount function that silently allows a 150% discount, or rounds $19.995 down instead of up, doesn't fail loudly in a code review; it fails quietly in a refund queue three weeks later. Teams that ship this kind of function without edge-case tests routinely discover the bug only after a customer notices they were overcharged or undercharged, at which point it's a support ticket and a manual reconciliation instead of a five-minute fix caught in CI.
À quoi nous l'utilisons
You're a backend developer at a mid-size e-commerce company. You just finished writing a discount-calculation function for the checkout flow, code review is in 20 minutes, and you haven't written a single test yet.
Prompt
Role: You are a senior QA engineer and test architect with expertise in [PROGRAMMING LANGUAGE] and [TESTING FRAMEWORK]. Context: I'm about to ship the following function/feature to production. Here is the code and its intended behavior: [PASTE CODE OR FUNCTION DESCRIPTION HERE]. This function will be called by [DESCRIBE CALLING CONTEXT, e.g., "a public API endpoint that receives untrusted user input" or "an internal batch job processing financial records"]. Task: Generate a comprehensive test suite for this function. Include: (1) happy-path unit tests covering the documented behavior, (2) edge cases (boundary values, empty/null inputs, extremely large inputs), (3) error scenarios and how the function should fail, (4) at least [NUMBER] integration test outlines describing how this function interacts with [DEPENDENT SYSTEM OR MODULE]. Constraints: Do not test implementation details that would break on refactor — test behavior, not internals. Flag any inputs where the expected behavior is ambiguous rather than guessing. Use [TESTING FRAMEWORK] syntax and conventions. Keep each test focused on one assertion or one logical scenario. Output Format: Organize as four sections with headers (Happy Path, Edge Cases, Error Scenarios, Integration Tests). For each test, give: a one-line description, the test code block, and a one-sentence note on what would break if this test failed. End with a short list of any ambiguous behaviors you flagged.
Résultat
Happy Path
Test: standard 20% discount applies correctly.def test_standard_discount():
assert apply_discount(100.0, 20.0) == 80.0
Breaks if: basic discount math regresses — the most visible failure a customer would notice immediately.
Edge Cases
Test: zero discount returns original price.def test_zero_discount():
assert apply_discount(50.0, 0.0) == 50.0
Breaks if: a no-op discount accidentally changes price via floating-point drift.
Test: 100% discount returns exactly zero.def test_full_discount():
assert apply_discount(75.0, 100.0) == 0.0
Breaks if: rounding leaves a residual charge like $0.01 on a 'free' item.
Test: price with sub-cent rounding boundary.def test_rounding_boundary():
assert apply_discount(19.99, 33.33) == 13.33
Breaks if: rounding mode rounds against the customer instead of to standard cents.
Error Scenarios
Test: negative discount percentage raises ValueError.def test_negative_discount_raises():
with pytest.raises(ValueError):
apply_discount(100.0, -10.0)
Breaks if: a negative discount silently increases the price instead of being rejected.
Test: discount over 100% raises ValueError.def test_over_100_percent_raises():
with pytest.raises(ValueError):
apply_discount(100.0, 150.0)
Breaks if: a checkout coupon bug applies a 150% discount and pays the customer to buy the item.
Integration Tests
1. Checkout API: verify the applied discount is persisted to the order record with the same rounding as the response body, so invoice totals match what the customer saw at checkout.
2. Coupon service: verify a discount capped by business rules (e.g. max $50 off) is enforced even when a stacked promo code would mathematically exceed it.
Ambiguous behaviors flagged: Should exactly 100.0% be allowed, or only up to 99.99%? Should the function round half-up or round-to-even (banker's rounding) at the cent boundary? Both need a product decision before the tests can be finalized.
Écrire des tests sous la pression d'un délai signifie presque toujours écrire les tests les plus faciles à imaginer, pas ceux qui détecteraient réellement un bug en production. Une fonction reçoit un test de chemin nominal parce que c'est le cas que le développeur vient de coder — les cas limites qui détecteraient une remise négative, une entrée nulle ou une erreur d'arrondi à la limite du centime sont omis.
Pourquoi le prompt exige quatre catégories, pas juste "écris des tests"
Demander à une IA d'"écrire des tests pour cette fonction" produit exactement le même angle mort qu'un développeur pressé : une couverture principalement du chemin nominal avec un ou deux cas limites symboliques. Forcer la sortie en quatre catégories nommées — chemin nominal, cas limites, scénarios d'erreur et tests d'intégration — transforme chaque catégorie en élément de liste de contrôle.
Pourquoi chaque test a besoin d'une note "ce qui casse si ça échoue"
Une liste de noms de tests n'aide pas un relecteur à déterminer si la suite est réellement suffisante — elle prouve seulement que des tests existent. Exiger une phrase sur la défaillance réelle que chaque test détecterait transforme la sortie en quelque chose qu'un relecteur peut réellement évaluer pour des lacunes de couverture.
Pourquoi il refuse de deviner un comportement ambigu
Les prompts de génération de tests qui produisent toujours une suite confiante et d'apparence complète sont dangereux précisément parce qu'ils semblent dignes de confiance. Forcer le modèle à signaler l'ambiguïté plutôt qu'à la résoudre protège contre des tests qui figent silencieusement une supposition non revue comme source de vérité du code.
Pourquoi il demande des ébauches d'intégration, pas juste plus de tests unitaires
Les tests unitaires valident une fonction isolément, mais la plupart des incidents de production se produisent à la jonction de deux unités fonctionnant correctement chacune séparément. Demander des ébauches de tests d'intégration par rapport au contexte d'appel permet de détecter la classe de bugs qui passe tous les tests unitaires mais corrompt quand même un total visible par le client.