Unit-Tests generieren, die Sie dann gegen die Spezifikation prüfen
Den fünften öden Test für eine Funktion zu schreiben, ist genau die Arbeit, die Entwickler gerne abgeben — Testgenerierung gehört laut JetBrains-Umfrage zu den Top-KI-Aufgaben, und Qodos Daten zeigen, dass Entwickler, die KI zum Testen nutzen, deutlich mehr Vertrauen in ihre Testsuite haben (61% gegenüber 27%). Der Haken: Ein Test, der allein aus dem Code entsteht, kodiert nur das, was der Code bereits tut — Bugs inklusive.
Sie sind ein erfahrener Test Engineer. Schreiben Sie Unit-Tests für die Funktion, die ich einfüge, entsprechend dem Teststil meines Projekts. Sprache und Test-Framework: {{framework}} Die zu testende Funktion: {{code}} Das beabsichtigte Verhalten, in meinen eigenen Worten (die Spezifikation): {{spec}} Erstellen Sie: 1. Eine kurze Liste von Verhaltensweisen und Randfällen, die es wert sind, getestet zu werden, abgeleitet aus dem beabsichtigten Verhalten — nicht nur aus dem, was der Code aktuell tut. Beziehen Sie Grenzwerte, leere und Null-Eingaben, Fehlerpfade und jede von mir beschriebene Invariante ein. 2. Den Testcode, ein klar benannter Test pro Verhalten, gemäß {{framework}}-Konventionen. 3. Einen Hinweis auf jedes Verhalten, das Sie nicht testen konnten, weil die Spezifikation mehrdeutig ist oder eine Abhängigkeit gemockt werden müsste. Regeln: - Wo das tatsächliche Verhalten des Codes dem von mir beschriebenen beabsichtigten Verhalten widerspricht, schreiben Sie einen FEHLSCHLAGENDEN Test, der das beabsichtigte Verhalten prüft, und markieren Sie ihn — passen Sie den Test nicht an einen möglichen Bug an. - Verwenden Sie nur Framework, Assertions und Mocking-Werkzeuge, die für {{framework}} Standard sind; importieren Sie keine Pakete oder Helfer, deren Existenz Sie nicht sicher wissen. - Prüfen Sie nicht auf private Interna oder exakte Log-Strings, das würde die Tests brüchig machen.
Tragen Sie Ihre Angaben ein — der Prompt aktualisiert sich live. Dann kopieren.
Zu testende Verhaltensweisen: normaler Rabatt angewendet; Rabatt gedeckelt, sodass der Preis nie negativ wird; negativer Preis abgelehnt; Null-Kunde behandelt; Bestellung mit Menge null. # pytest def test_applies_percentage_discount(): assert final_price(100, 0.2) == 80 def test_rejects_negative_price(): with pytest.raises(ValueError): final_price(-1, 0.2) Hinweis: Ihre Spezifikation besagt, der Preis soll nie unter null fallen, aber der Code liefert bei Rabatten über 100% einen negativen Wert. Ich habe test_price_never_negative als FEHLSCHLAGENDEN Test geschrieben, der das beabsichtigte Verhalten prüft. Rundung von Währungsbeträgen konnte ich nicht testen — die Spezifikation definierte das nicht.
Der komplette Arbeitsablauf
- Schreiben Sie zuerst selbst das beabsichtigte Verhalten auf — die Spezifikation, nicht nur das, was der Code tut
- Generieren Sie die Tests und lesen Sie dann jeden einzelnen, um zu bestätigen, dass er tatsächlich das prüft, was Sie wollen
- Führen Sie die Testsuite aus; untersuchen Sie jeden Fehlschlag als möglichen echten Bug, nicht als zum Schweigen zu bringenden Test
- Ergänzen Sie die vom Modell übersehenen Fälle und löschen Sie die brüchigen oder redundanten
Worauf Sie achten sollten
Tests, die allein aus dem Code generiert werden, bestehen per Konstruktion und beweisen nichts — sie zementieren das aktuelle Verhalten, Bugs inklusive. Liefern Sie das beabsichtigte Verhalten separat und prüfen Sie, ob ein fehlschlagender Test auf einen echten Defekt hinweist.
Prüfen Sie, ob jede vom Modell importierte Bibliothek oder jeder Test-Helper tatsächlich existiert. Studien fanden, dass etwa jedes fünfte von KI vorgeschlagene Paket halluziniert ist, und Angreifer registrieren diese Namen als Malware (ein Supply-Chain-Trick namens Slopsquatting) — fügen Sie KI-vorgeschlagene Abhängigkeiten nie ungeprüft hinzu.
Halten Sie proprietären Code und echte Kundendaten von Consumer-KI-Tools fern — nutzen Sie Dummy-Fixtures oder eine Enterprise-Stufe mit deaktiviertem Training.
Woher das stammt
Jeder Anwendungsfall auf dieser Website beruht auf echten Berichten, die Softwareentwickler aus der Praxis geteilt haben — nichts davon ist von uns erfunden.