Skip to content

AI Tools für automatisierte Tests

AI Tools für automatisierte Tests: Unit Tests, Integration Tests und E2E Tests mit Claude & ChatGPT generieren. 10 Prompts für Jest, Vitest, Cypress, Playwright + TDD-Workflow.

Einleitung

Tests schreiben ist die Aufgabe, die am häufigsten „auf morgen“ verschoben wird. KI-Tools ändern das grundlegend: Du kannst eine komplette Test-Suite in Minuten generieren lassen – und das in einer Qualität, die oft besser ist als manuell geschriebene Tests.

In diesem Artikel zeige ich dir 10 Prompts für die automatische Test-Generierung mit KI und einen kompletten TDD-Workflow mit AI-Unterstützung.


Ebenfalls empfehlenswert ist eine regelmäßige Überprüfung der Ergebnisse.

Inhaltsverzeichnis

  1. Warum AI-generierte Tests?
  2. Prompt 1: Unit Tests generieren
  3. Prompt 2: Edge Cases finden
  4. Prompt 3: Mocks & Stubs erstellen
  5. Prompt 4: Integration Tests
  6. Prompt 5: E2E Tests (Playwright/Cypress)
  7. Prompt 6: TDD mit AI
  8. Prompt 7: Mutation Testing
  9. Prompt 8: Snapshot Tests
  10. Prompt 9: Performance Tests
  11. Prompt 10: Coverage-Lücken schließen
  12. Der KI-gestützte TDD-Workflow
  13. Tool-Vergleich: Wer generiert die besten Tests?
  14. FAQ

Deshalb ist es wichtig, diesen Abschnitt aufmerksam zu lesen.

Warum AI-generierte Tests?

Außerdem gibt es hilfreiche Tools, die dich dabei unterstützen.

  • Geschwindigkeit: 50 Test Cases in 2 Minuten statt 2 Stunden
  • Vollständigkeit: Zudem kI denkt an Edge Cases, die Entwickler übersehen
  • Konsistenz: Einheitlicher Style und Namenskonventionen
  • Motivation: Wenn Tests „kostenlos“ sind, schreibt man mehr davon
  • Lerneffekt: KI-Tests zeigen dir Testmuster, die du noch nicht kanntest

Im Grunde sparst du dadurch langfristig viel Zeit.

Prompt 1: Unit Tests generieren

Tatsächlich ist dieser Bereich besonders wichtig für Entwickler.

Generiere vollständige Unit Tests für diese Funktion/Klasse:

```[sprache]
[Code einfügen]
```

Test-Framework: [Jest / Vitest / pytest / etc.]

Anforderungen:
1. Teste jeden öffentlichen Methoden-/Funktions-Pfad
2. Happy Path (normaler Gebrauch)
3. Edge Cases (leere Eingaben, null, undefined, Grenzwerte)
4. Error Cases (ungültige Eingaben, Exceptions)
5. Boundary Values (0, -1, MAX_INT, leere Strings)
6. Beschreibende Testnamen: "should [erwartetes Verhalten] when [Bedingung]"
7. AAA-Pattern: Arrange → Act → Assert
8. Keine Test-Logik in Variablen verstecken
9. Jeder Test testet genau EINE Sache

Tatsächlich lässt sich dieser Code direkt in dein Projekt übernehmen.


Insbesondere für fortgeschrittene Projekte ist das relevant.

Prompt 2: Edge Cases finden

Deshalb lohnt es sich, dieses Thema genauer zu betrachten.

Analysiere diese Funktion und finde ALLE Edge Cases:

```[sprache]
[Code einfügen]
```

Für jeden Edge Case:
1. Beschreibung des Szenarios
2. Eingabe-Werte die den Edge Case auslösen
3. Erwartetes Verhalten (was SOLL passieren?)
4. Aktuelles Verhalten (was PASSIERT tatsächlich?)
5. Priorität: Critical / Important / Nice-to-have
6. Test-Code für den Edge Case

Kategorien die du prüfen sollst:
- Null/Undefined/NaN
- Leere Strings/Arrays/Objekte
- Maximale und minimale Werte
- Unicode und Sonderzeichen
- Concurrent Access
- Timeout-Szenarien
- Zirkuläre Referenzen

Natürlich solltest du den generierten Code vor dem Einsatz testen.


Natürlich kannst du den Ansatz an deine Bedürfnisse anpassen.

Prompt 3: Mocks & Stubs erstellen

Ebenso wichtig ist es, die Best Practices zu kennen.

Erstelle Mocks und Stubs für die externen Dependencies in diesem Code:

```[sprache]
[Code mit externen Dependencies (DB, API, FileSystem, etc.)]
```

Für jede Dependency:
1. Mock-Implementierung mit realistischen Return-Werten
2. Mock für Success-Case
3. Mock für Error-Case (Netzwerkfehler, Timeout, 500er)
4. Type-safe Mocks (TypeScript-kompatibel)
5. Reset-Funktion für Clean-Up zwischen Tests
6. Spy-Funktionalität zum Überprüfen der Aufrufe

Zusätzlich:
- Factory-Funktion für Test-Daten (createTestUser(), createTestOrder())
- Builder-Pattern für komplexe Test-Objekte
- Gemeinsame Setup/Teardown-Funktionen

Dabei zeigt dieses Beispiel den grundlegenden Ansatz.


Zusätzlich gibt es einige bewährte Tipps für den Alltag.

Prompt 4: Integration Tests

Zusammenfassend lässt sich sagen, dass dies ein zentraler Aspekt ist.

Generiere Integration Tests für diese API-Route/Service-Methode:

```[sprache]
[Route + Service + Repository Code]
```

Die Tests sollen:
1. Den gesamten Stack testen (Route → Service → Repository)
2. Echte HTTP-Requests mit Supertest/Fastify.inject simulieren
3. Test-Datenbank nutzen (Setup + Teardown pro Test)
4. Authentication/Authorization mit Test-Token prüfen
5. Datenbank-State vor und nach der Operation verifizieren
6. Transaktions-Rollback für Clean-Up

Test-Szenarien:
- CRUD-Operationen (Create, Read, Update, Delete)
- Ungültige Requests (Validierung)
- Nicht-authentifizierte Requests
- Concurrent Modifications
- Cascade-Effekte (Löschen von Parent → Children)

Hierbei hilft es, von konkreten Beispielen auszugehen.

Prompt 5: E2E Tests (Playwright/Cypress)

Insbesondere für den Einstieg sind die folgenden Informationen hilfreich.

Generiere E2E Tests für diesen User-Flow:

App: [z.B. "E-Commerce Checkout"]
Schritte:
1. [z.B. "User öffnet Produktseite"]
2. [z.B. "Klickt 'In den Warenkorb'"]
3. [z.B. "Geht zum Checkout"]
4. [z.B. "Füllt Adressformular aus"]
5. [z.B. "Wählt Zahlungsmethode"]
6. [z.B. "Bestätigt Bestellung"]

Framework: [Playwright / Cypress]

Die Tests sollen:
1. Page Object Model nutzen (separate Klassen pro Seite)
2. Realistische Test-Daten verwenden
3. Auf CI/CD optimiert sein (keine flaky Tests)
4. Screenshots bei Fehlern machen
5. Viewport-Größen testen (Desktop + Mobile)
6. Accessibility-Checks einbauen (axe-core)
7. Netzwerk-Mocking für externe Services

Ebenfalls sinnvoll ist es, verschiedene Varianten auszuprobieren.


Ebenso hilfreich ist ein strukturierter Ansatz bei der Umsetzung.

Prompt 6: TDD mit AI

Dennoch solltest du einige Besonderheiten beachten.

Ich möchte eine neue Funktion mit TDD entwickeln:

Anforderung: [z.B. "Funktion die eine Kreditkartennummer validiert (Luhn-Algorithmus)"]

Führe mich durch den TDD-Zyklus:

Runde 1 (RED):
- Schreibe den einfachsten Test, der feilst
- Zeige den Test-Code

Runde 2 (GREEN):
- Schreibe den minimalen Code, der den Test bestehen lässt
- Zeige den Implementierungs-Code

Runde 3 (REFACTOR):
- Verbessere den Code ohne das Verhalten zu ändern

Wiederhole für mindestens 5 Runden mit zunehmender Komplexität:
- Runde 1: Grundfall
- Runde 2: Validierung
- Runde 3: Edge Cases
- Runde 4: Error Handling
- Runde 5: Performance

Insbesondere die Struktur des Prompts ist dabei entscheidend für gute Ergebnisse.


Dennoch sollte man die Limitierungen im Blick behalten.

Prompt 7: Mutation Testing

Weiterhin ist es wichtig, die Grundlagen zu verstehen.

Führe ein manuelles Mutation Testing für diesen Code und seine Tests durch:

Code:
```[sprache]
[Implementierung]
```

Tests:
```[sprache]
[Bestehende Tests]
```

1. Erstelle 10 Mutationen des Codes (kleine Änderungen die Bugs einführen):
   - Operator-Änderungen (+→-, &&→||, >→>=)
   - Boundary-Änderungen (< statt <=)
   - Entfernte Bedingungen (if-Block entfernen)
   - Geänderte Rückgabewerte
   - Entfernte Aufrufe

2. Für jede Mutation: Wird sie von den bestehenden Tests erkannt? (Killed/Survived)

3. Für überlebende Mutationen: Schreibe den fehlenden Test

4. Berechne den Mutation Score: Killed / Total

Vor allem die detaillierten Anweisungen sorgen für präzisere Ergebnisse.


Somit ergibt sich ein klarer Vorteil gegenüber manuellen Methoden.

Prompt 8: Snapshot Tests

Dementsprechend solltest du die folgenden Aspekte kennen.

Generiere sinnvolle Snapshot Tests für diese React/Vue-Komponenten:

```[sprache]
[Komponenten-Code]
```

Regeln:
1. Ein Snapshot pro sinnvollem Zustand (nicht für jede Prop-Kombination)
2. Teste: Default-State, Loading-State, Error-State, Empty-State
3. Teste verschiedene Prop-Varianten die das Rendering beeinflussen
4. Inline Snapshots für kleine Komponenten
5. KEINE Snapshot Tests für: dynamische Inhalte (Timestamps, IDs)
6. Erkläre bei jedem Test, warum dieser Snapshot sinnvoll ist

Dementsprechend solltest du die einzelnen Schritte sorgfältig abarbeiten.

Prompt 9: Performance Tests

Ebenfalls relevant sind die praktischen Anwendungsbeispiele.

Generiere Performance Tests für diese Funktion:

```[sprache]
[Code]
```

Implementiere:
1. Benchmark-Test: Messe die Ausführungszeit mit verschiedenen Input-Größen
   (10, 100, 1.000, 10.000, 100.000 Elemente)
2. Memory-Test: Prüfe den Speicherverbrauch
3. Regression-Guard: Test der fehlschlägt wenn die Funktion langsamer wird als [X]ms
4. Big-O Analyse: Schätze die Zeitkomplexität basierend auf den Benchmark-Ergebnissen
5. Vergleichs-Benchmark: Vergleiche mit alternativen Implementierungen
6. Ergebnisse als Tabelle formatieren

Außerdem kannst du den Prompt für verschiedene Programmiersprachen anpassen.


Vor allem in der Praxis hat sich dieser Workflow bewährt.

Prompt 10: Coverage-Lücken schließen

Im Grunde vereinfacht dieser Ansatz den gesamten Workflow erheblich.

Hier ist mein Code und der aktuelle Coverage-Report:

Code:
```[sprache]
[Code]
```

Bestehende Tests:
```[sprache]
[Tests]
```

Nicht abgedeckte Zeilen: [z.B. "Zeilen 45-52, 78, 93-101"]

1. Analysiere: Warum sind diese Zeilen nicht abgedeckt?
2. Sind es Error-Pfade, Edge Cases oder tote Code-Pfade?
3. Generiere Tests die diese Zeilen abdecken
4. Falls es toter Code ist: Markiere ihn zum Löschen
5. Priorisiere: Welche fehlende Abdeckung ist am riskantesten?

Im Grunde funktioniert dieser Ansatz mit allen gängigen AI-Tools.


Tatsächlich zeigt die Praxis, dass dieser Ansatz sehr effektiv ist.

Der KI-gestützte TDD-Workflow

Vor allem für den praktischen Einsatz sind diese Informationen wertvoll.

So integrierst du KI optimal in deinen Test-Workflow:

  1. Feature definieren: Beschreibe das Feature in natürlicher Sprache
  2. Tests zuerst: Lasse die KI Unit Tests basierend auf der Beschreibung generieren (Prompt 6)
  3. Implementieren: Schreibe den Code (mit oder ohne KI-Hilfe)
  4. Edge Cases: Lasse die KI Edge Cases identifizieren (Prompt 2)
  5. Refactoring: Code verbessern, Tests müssen weiterhin grün sein
  6. Integration Tests: Für kritische Pfade (Prompt 4)
  7. Mutation Testing: Prüfe die Qualität deiner Tests (Prompt 7)
  8. Coverage prüfen: Lücken schließen (Prompt 10)

Pro-Tipp: Frage die KI nach jedem Feature: „Welche Tests fehlen noch? Wo könnten Bugs lauern, die meine Tests nicht abdecken?"


Allerdings gibt es dabei einige Punkte, die du beachten solltest.

Tool-Vergleich: Wer generiert die besten Tests?

Somit kannst du direkt mit der Umsetzung beginnen.

KriteriumClaudeChatGPTGitHub Copilot
Unit Tests⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
Edge Cases⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
Mocks⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
E2E Tests⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
IDE-Integration⭐⭐ (via Cursor)⭐⭐⭐⭐⭐⭐⭐
Großer Kontext⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐

Empfehlung: Claude für Test-Generierung per Chat. GitHub Copilot für inline Test-Generierung direkt im Editor. Beide zusammen für maximale Produktivität.


Grundsätzlich empfiehlt es sich, schrittweise vorzugehen.

FAQ

Sind AI-generierte Tests zuverlässig?

Folglich profitierst du von einem besseren Verständnis dieser Konzepte.

Ja, wenn du sie reviewst. Die häufigsten Probleme: falsche Assertions (testet nicht was es soll), fehlende Edge Cases, und Mocks die nicht zum echten Verhalten passen. Immer den Test laufen lassen und das Ergebnis prüfen.

Wie viel Coverage soll ich anstreben?

Dabei spielen mehrere Faktoren eine wichtige Rolle.

80% Coverage ist ein guter Standard. 100% ist selten sinnvoll (toter Code, triviale Getter). Wichtiger als die Zahl: Kritische Business-Logik muss 100% abgedeckt sein.

Unit Tests oder Integration Tests?

Natürlich gibt es dabei verschiedene Herangehensweisen.

Beides. Die Testing-Pyramide: Viele Unit Tests (schnell, billig), weniger Integration Tests (langsamer, realistischer), wenige E2E Tests (langsam, teuer, aber nah am User). KI macht alle drei günstiger.

Kann die KI auch bestehende Tests verbessern?

Darüber hinaus bietet dieser Abschnitt konkrete Beispiele und Tipps.

Absolut. Gib der KI bestehende Tests und frage: „Sind diese Tests gut? Was fehlt? Welche Tests sind fragile oder testen Implementation Details statt Verhalten?"

Wie gehe ich mit flaky Tests um?

Grundsätzlich gibt es dabei einige Punkte zu beachten.

Gib der KI den flaky Test und frage: „Warum ist dieser Test nicht deterministisch? Wie mache ich ihn stabil?" Häufige Ursachen: Timing-Abhängigkeiten, nicht aufgeräumter State, Racing on shared resources.


Im Folgenden gehe ich auf die wichtigsten Details ein.

Verwandte Artikel:


Außerdem profitierst du von einem systematischen Vorgehen.

Zuletzt aktualisiert: März 2026