Eine vollständige Testsuite aus jeder Funktion oder Funktionsbeschreibung generieren
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)
Das Problem des manuellen Schreibens von Tests
Fragen Sie jeden Entwickler, was er unter Termindruck auslässt, und Tests kommen jedes Mal zur Sprache. Nicht weil Entwickler sich nicht um Qualität kümmern — tun sie — sondern weil das Schreiben umfassender Tests mühsam, repetitiv und geistig anstrengend ist. Man muss in Gegensätzen denken: Was bricht das? Was habe ich nicht bedacht? Die meisten Entwickler verpassen in diesem Modus 30-40 % der bedeutenden Edge Cases.
Dieser Prompt löst das Problem, indem er das systematische Denken eines Senior QA-Ingenieurs in eine wiederverwendbare Vorlage einbettet.
Was diesen Prompt effektiv macht
Der Prompt verwendet ein Fünf-Kategorien-Abdeckungs-Framework: Happy Path, Edge Cases, Fehler, Integration und Sicherheit. Jede Kategorie ist einem anderen Fehlermodus in der Produktion zugeordnet. Die Einschränkung, Tests mit should_[behavior]_when_[condition] zu benennen, zwingt die KI präzise zu sein, anstatt vage Namen wie test_1 oder testFunction_works zu generieren. Die Anforderung, Testbarkeitsprobleme zu markieren, erfasst architektonische Probleme — wie stark gekoppelte Abhängigkeiten — bevor sie zu technischen Schulden werden.
Wie man es verwendet
Fügen Sie den Prompt in Claude Sonnet 4.5 (oder GPT-4o) ein. Füllen Sie die drei eingeklammerten Felder aus: Ihre Programmiersprache, Ihr Test-Framework und die Funktions- oder Funktionalitätsbeschreibung. Fügen Sie für eine Funktion den eigentlichen Code ein. Fügen Sie für eine Funktionalität die Akzeptanzkriterien oder eine einfache englische Beschreibung dessen ein, was sie tut.
Die Ausgabe ist eine ausführbare Testdatei plus eine Zusammenfassungstabelle der Abdeckung. Führen Sie sie aus, überprüfen Sie die skizzierten Tests, die ausgearbeitet werden müssen, und Sie haben in Minuten statt Stunden eine Basis-Testsuite.
Anpassung für verschiedene Sprachen und Frameworks
Der Prompt funktioniert gleichermaßen gut in allen Ökosystemen. Geben Sie für Python pytest als Framework an. Verwenden Sie für TypeScript Jest oder Vitest. Verwenden Sie für Java JUnit 5. Sagen Sie für Go einfach Go testing package. Die Ausgabestruktur passt sich entsprechend an — die KI kennt die Idiome jedes Frameworks und verwendet den korrekten Assertion-Stil, Mock-Muster und die richtige Dateiorganisation.
Beispielausgabe-Vorschau
Für eine Funktion calculateDiscount(price, memberTier) in TypeScript mit Jest generiert der Prompt etwa 18–24 Tests, die abdecken: Standard-Preis/Mitgliedsstufen-Kombinationen, Null-Preis-Eingaben, negative Preise, ungültige Stufenzeichenfolgen, Nullparameter, Gleitkomma-Grenzfälle und den Integrationsvertrag mit dem Preisdienst. Die Zusammenfassungstabelle zeigt eine geschätzte Zeilenabdeckung von über 90 %.