Unit-Tests schreiben
Tests, die Fehler finden statt Code abzudecken: Randfälle, Fehlerpfade, sprechende Namen.
Du bist Test-Engineer/in und schreibst Tests, die Fehler finden, nicht Coverage erzeugen. CODE [CODE] SPRACHE UND FRAMEWORK [SPRACHE, TESTFRAMEWORK] WAS GETESTET WERDEN SOLL [FUNKTION ODER VERHALTEN] AUSGABE 1) WAS GETESTET WIRD — eine Liste der Fälle: Normalfall, Randfall, Fehlerfall, Grenzwert. 2) TESTS — vollständig, mit sprechenden Namen, die das Verhalten beschreiben. 3) BEGRÜNDUNG — warum jeder Fall zählt. 4) WAS NICHT GETESTET WIRD — und warum (Implementierungsdetails, Glue-Code). 5) LÜCKEN — welche Fälle ich selbst ergänzen muss, weil ich die Anforderungen kenne. REGELN - Keine Tests, die die Implementierung prüfen (private Methoden, Reihenfolge von Aufrufen), außer es ist das Verhalten. - Randfälle: leer, null, zu groß, negativ, Unicode, Grenzwerte. - Ein Test, eine Aussage. Keine Testmethode mit fünf Asserts zu verschiedenen Themen. - Keine externen Dienste: alles, was Netzwerk oder Dateien braucht, wird ersetzt.
Ein Test beschreibt Verhalten. Wer Implementierung beschreibt, schreibt Wartung.
02 — Variablen
Eckige Klammern füllen
Die hervorgehobenen Felder sind die Stellen für deine Angaben. Du musst nicht alle füllen: Was leer bleibt, ergänzt das Modell nach eigenem Ermessen.
[CODE]
[SPRACHE, TESTFRAMEWORK]
[FUNKTION ODER VERHALTEN]
03 — Anwendung
So gehst du Schritt für Schritt vor
- 01
Randfälle finden mehr Fehler als der Normalfall: leer, null, negativ, Grenzwert, Unicode.
- 02
Ein Test, eine Aussage: sonst weißt du beim Fehlschlag nicht, was kaputt ist.
- 03
Tests, die die Implementierung prüfen, brechen bei jedem Refactoring und finden keinen Fehler.
04 — Varianten
Derselbe Prompt, anderes Ergebnis
Ein Prompt deckt nicht jeden Fall ab. Diese Varianten verlangen dieselbe Arbeit in anderem Ton, anderer Länge oder anderem Format: nimm die, die passt.
API
Gleiche Struktur für API-Tests: Statuscodes, Fehlerformat, Validierung, Authentifizierung, Rate Limit.
Datenbank
Gleiche Struktur für Datenbanktests: Testdatenbank, Transaktionen zurückrollen, Migrationsstand, keine Produktionsdaten.
05 — Tipps
Hinweise, die das Ergebnis eine Stufe heben
- Coverage ist eine Zahl, nicht eine Qualität: 80 % ohne Randfälle schützt weniger als 50 % mit.
- Ein Test, der nach einem Refactoring bricht, obwohl das Verhalten gleich ist, prüft die falsche Sache.
06 — Fragen
Häufige Fragen zu Programmierung
Wie viele Tests sind genug?
Alle Randfälle plus der Normalfall. Nicht jede Zeile braucht einen Test.
Sollte ich vor oder nach dem Code testen?
Für neuen Code vorher (TDD), für bestehenden Code mit Charakterisierungstests zuerst das Verhalten festhalten.
Weiter
Das könnte dir auch helfen
Prompt für wartbaren Code
Code, den jemand in sechs Monaten warten kann: Versionen, Randfälle, Fehlerbehandlung und Tests von Anfang an.
Fortgeschritten ChatGPTClaudePrompt zum Debuggen: Hypothese statt Raten
Debuggen mit Hypothesen statt Ausprobieren: vollständige Fehlermeldung, Reproduktion und die wahrscheinlichste Ursache zuerst.
Fortgeschritten ChatGPTClaudeRefactoring-Prompt: Verhalten bleibt gleich
Refactoring ohne Regressionsrisiko: öffentlicher Vertrag bleibt, Tests zuerst, jeder Schritt einzeln prüfbar.
Profi ChatGPTClaudePython-Code-Prompt mit Tests
Python, das läuft: Version, Typen, Fehlerbehandlung, Beispielaufruf und Tests statt Snippet ohne Kontext.
FortgeschrittenDiese Seite hat das CopyPromt-Redaktionsteam erstellt; sie wurde erstmals am 25 Oktober 2026 veröffentlicht. Die Prompts sind für den Einsatz in mehreren Modellen geschrieben; Markennamen werden nur zur Kennzeichnung genannt.