Testing mit Claude Code: Unit-, Integrations- und E2E-Tests erklärt

Stell dir vor, du entwickelst monatelang an einer Anwendung. Nach jedem Update willst du sicher sein, dass die neuen Funktionen nichts Bestehendes kaputt gemacht haben. Wenn du dafür jedes Mal selbst durch alle Funktionen klickst, wird das schnell unmöglich. Professionelle Entwickler:innen lösen das mit automatisierten Tests, und sie achten sehr genau darauf, dass dieser Schritt nicht vergessen wird.

In diesem Artikel zeige ich dir, welche Testebenen es gibt und wann du welche brauchst, wie Claude Code die Tests für dich schreibt und ausführt und wie du ganze Nutzerabläufe automatisch im Browser testen lässt.

Warum deine Claude-Code-App automatisierte Tests braucht

Die meisten Anleitungen zu Claude Code zeigen, wie du möglichst schnell eine App baust. Testing kommt darin kaum vor. Das Problem: Wenn du keine automatisierten Tests hast, gibt es in deiner Anwendung mit hoher Wahrscheinlichkeit Fehler, von denen du nichts weißt.

Jede Änderung, die Claude macht, kann an einer anderen Stelle etwas beschädigen. Ein Test ist ein kleines Programm, das prüft, ob eine Funktion noch das tut, was sie soll. Läuft es nach jeder Änderung durch, bemerkst du Fehler sofort und nicht erst, wenn sich ein Nutzer beschwert.

Die Testpyramide: Unit-, Integrations- und E2E-Tests

Es gibt drei Arten von Tests. Man stellt sie oft als Pyramide dar: unten viele kleine, schnelle Tests, oben wenige große, aufwendige.

E2E-Tests sind am aufwendigsten, kommen aber einer echten Nutzererfahrung am nächsten.

Das Schöne an Claude Code: Du musst nicht selbst entscheiden, welche Testart und welches Framework du brauchst. Wenn du Claude gezielt bittest, Tests für einen bestimmten Ablauf zu schreiben, wählt er das passende Test-Framework für deinen Stack.

Das Beispielprojekt: ein kleines Projektmanagement-Tool

Um alle drei Ebenen in der Praxis zu zeigen, habe ich ein kleines Projektmanagement-Tool entwickeln lassen: ein Kanban-Board, auf dem man Aufgaben anlegen und per Drag and Drop verschieben kann, davor Registrierung und Login. Die Daten liegen zunächst nur im Browser-Speicher, ein echtes Backend gibt es noch nicht.

Ich arbeite dabei mit einem festen Entwicklungsablauf, der ein Entwicklungsteam nachbildet. Jede Rolle ist ein eigener Skill, also eine Arbeitsanleitung, die Claude bei Bedarf lädt:

1. Requirements Engineer: nimmt die Anforderungen auf und schreibt pro Feature eine Spezifikation.
2. Solution Architect: erstellt das technische Design.
3. Frontend- und Backend-Developer: setzen das Feature um.
4. QA Engineer: prüft das Feature auf Herz und Nieren. Um diese Rolle geht es hier vor allem.
5. DevOps: sorgt dafür, dass die App richtig veröffentlicht wird.

Der Startprompt war kurz:

Bitte hilf mir, ein neues Projekt zu initialisieren. Ich möchte einen kleinen Testcase entwickeln: ein simples Projektmanagement-Tool mit einem Kanban-Board, auf dem ich Aufgaben erstellen und per Drag and Drop verschieben kann. Davor geschaltet sollen eine Benutzerregistrierung und ein Login sein. Alles soll erstmal lokal im Browser gespeichert werden, es gibt noch kein echtes Backend.

Claude hat mir daraufhin Rückfragen gestellt: Wer sind die Nutzer? Welche Spalten braucht das Board? Was gehört zu einer Aufgabe? Wie läuft die Registrierung? Daraus entstanden drei Features: Benutzer-Authentifizierung, Kanban-Board mit Aufgabenverwaltung und Drag and Drop.

Akzeptanzkriterien: die Grundlage für spätere Tests

Jede Feature-Spezifikation landet als eigene Datei in einem Ordner features. Eine index.md dient Claude als Projektmanagement und hält den Status jedes Features fest. In der Spezifikation selbst stehen:

• User Stories: was Nutzer:innen tun wollen,
• Akzeptanzkriterien: testbare Bedingungen, die erfüllt sein müssen, damit das Feature abgenommen wird,
• Edge Cases: Sonderfälle, die von Anfang an mitgedacht werden,
• technische Voraussetzungen.

Die Akzeptanzkriterien werden später für die E2E-Tests wichtig. Danach folgten technisches Design (Komponenten, Datenspeicherung, Technikentscheidungen, benötigte Pakete) und die Umsetzung. Registrierung, Login und Aufgaben anlegen funktionierten, das Verschieben gehörte zum dritten Feature und war noch nicht gebaut.

Ebene 1: Unit-Tests mit Claude Code

Wie der QA-Skill aufgebaut ist

Bevor der QA-Schritt läuft, lohnt ein Blick in den Skill. Er liegt unter .claude/skills/qa/SKILL.md und ist so aufgebaut:

• ein Header, der beschreibt, was der Skill macht und wann Claude ihn aufrufen soll,
• eine Rollenbeschreibung,
• Vorbedingungen, die Claude prüft, bevor er loslegt,
• die Arbeitsschritte, darunter das Schreiben von Unit-Tests, bevor E2E-Tests entstehen.

Für die Unit-Tests ist das Framework Vitest festgelegt. Die Testdateien liegen co-located, also direkt neben den Code-Dateien, die sie testen. Außerdem steht im Skill genau, was mit Unit-Tests getestet werden soll und was nicht. So hat Claude eine klare Anweisung.

Was Claude getestet hat

Nach dem QA-Durchlauf für das Feature Authentifizierung stehen die Ergebnisse direkt in der Feature-Datei im Abschnitt „QA Results“. Alle Akzeptanzkriterien waren erfüllt. Dazu gab es zwei kleinere Findings: ein kosmetisches Problem und eine zu allgemeine Fehlermeldung, die man durch eine spezifischere ersetzen könnte.

Für den Authentifizierungs-Service hat Claude eine ganze Reihe von Unit-Tests geschrieben, gruppiert nach Bereichen:

• Passwort-Hashing,
• Session-Management,
• Registrierung, zum Beispiel „registriert einen neuen Nutzer erfolgreich“ und „speichert das Passwort als Hash, nie im Klartext“,
• Login und Logout.

Was nicht per Unit-Test geprüft wird: reine UI-Komponenten, die nur etwas anzeigen. Das übernehmen später die E2E-Tests.

Die Grundidee von Unit-Tests: Sie laufen extrem schnell, prüfen präzise einen einzigen Baustein und melden sofort, wenn etwas kaputt ist.

So führt Claude die Tests aus

Claude startet einen Test-Runner über das Terminal:

npm test

Der Test-Runner prüft alle Funktionen nacheinander. Schlägt ein Test fehl, bekommt Claude die Fehlermeldung zurück und kann den Bug direkt beheben.

Unit-Tests ohne eigenen Skill

Du brauchst dafür keinen fertigen Skill. Wenn du eine Funktion implementiert hast, frag Claude einfach, ob ein Unit-Test sinnvoll ist, und fordere gezielt Testfälle für normales Verhalten, Sonderfälle und Fehlerfälle an:

Ist für die Funktion, die du gerade gebaut hast, ein Unit-Test sinnvoll? Wenn ja, schreib Unit-Tests für normales Verhalten, für Edge Cases und für Fehlerfälle. Lege die Testdateien co-located direkt neben die Code-Dateien und führe die Tests danach aus.

Ebene 2: Integrationstests

Bei Integrationstests geht es nicht mehr um einzelne Funktionen, sondern um ihr Zusammenspiel. Typisches Beispiel ist die Registrierung: Kann sich ein Nutzer registrieren, wird sein Account in der Datenbank angelegt, und bekommt er eine Bestätigungsmail?

In meinem Ablauf schreibt der Backend-Skill die Integrationstests, weil dort die meiste Anwendungslogik entsteht. Im Skill gibt es dafür einen eigenen Arbeitsschritt: Für jede API-Route wird ein Integrationstest angelegt, der den Normalfall („Happy Path“), Validierungsfehler und weitere Fehlerfälle abdeckt. Der Fokus liegt auf den API-Routen, weil das Projekt standardmäßig Supabase als Backend nutzt. Für andere Backends lässt sich das anpassen.

Im Beispielprojekt war der Nutzen begrenzt, weil es kein echtes Backend gibt. Claude hat trotzdem einen Integrationstest für den kompletten Registrierungsablauf geschrieben, mit Registrierung, Login, Logout und Session-Lebenszyklus. Die Datei liegt wieder neben dem Code, trägt „integration“ im Namen und beschreibt jeden Testfall in Klartext. Wirklich wertvoll werden Integrationstests an den Übergängen zwischen Systemen, also dort, wo deine App mit Datenbank, Zahlungsanbieter oder E-Mail-Dienst spricht.

Ein einfacher Integrationstest für die Registrierung kann so aussehen:

test('Registrierung erstellt User und sendet Bestätigungsmail', async () => {
  const result = await registerUser({
    email: 'neu@example.com',
    password: 'sicheresPasswort123'
  })

  expect(result.user).toBeDefined()
  expect(result.confirmationEmailSent).toBe(true)
})

Ohne Skill bittest du Claude einfach direkt darum:

Schreib mir einen Integrationstest für den Registrierungsablauf. Der Test soll den API-Aufruf, den Datenbankeintrag und die Response prüfen.

Du kannst Claude auch selbst ermitteln lassen, welche Abläufe in deinem Projekt sinnvollerweise per Integrationstest abgesichert werden sollten.

Mock-Daten oder echte Testdatenbank?

Integrationstests nutzen in meinem Setup keine echte Datenbank, sondern simulieren eine. Es gibt zwei Ansätze, beide sind legitim:

Wenn du mit einer App arbeitest, die bereits live ist, hilft dir außerdem eine getrennte Umgebung für die Entwicklung. Wie du sie aufsetzt, zeige ich in der Anleitung zur Testumgebung für Claude Code.

Ebene 3: End-to-End-Tests mit Playwright

E2E-Tests prüfen ganze Nutzerabläufe. Ein echter Browser wird gestartet, Seiten werden aufgerufen, Formulare ausgefüllt, Buttons geklickt. Das ist die realistischste, aber auch die aufwendigste Form des Testens. Deshalb setzt man sie meist nur für die Kernabläufe ein:

• Login und Registrierung,
• Checkout und Bezahlung,
• die Features, für die deine Nutzer:innen am Ende bezahlen.

Playwright einrichten

Für E2E-Tests brauchst du ein Hilfsmittel: Playwright. Es ist das Standardwerkzeug für E2E-Tests von Webanwendungen, wurde von Microsoft entwickelt, ist Open Source und kostenlos.

In einem neuen Projekt richtest du Playwright mit diesem Befehl ein, der auch die Konfiguration anlegt:

npm init playwright@latest

Ist Playwright schon im Projekt, lädst du die benötigten Browser mit:

npx playwright install

Einfacher geht es, wenn du Claude bittest, Playwright im Projekt zu installieren.

E2E-Tests schreiben lassen

Danach kannst du Claude bitten, E2E-Tests zu schreiben:

Schreib mir einen End-to-End-Test mit Playwright für den Login-Ablauf: Öffne die Login-Seite, gib E-Mail und Passwort ein, klick auf Login und prüfe, dass am Ende das Dashboard angezeigt wird.

Claude legt dann einen Testordner an und darin pro Test eine Datei mit der Endung .spec.ts. Ausführen kannst du alle Tests mit:

npx playwright test

Oder du bittest wieder Claude, die Tests zu starten.

E2E-Tests aus Akzeptanzkriterien

In meinem Ablauf schreibt der QA-Skill die E2E-Tests automatisch. Für jedes Akzeptanzkriterium aus der Feature-Spezifikation entsteht ein eigener Test. Darum musst du dich also nicht separat kümmern.

Die Tests liegen standardmäßig im Ordner tests, die Datei trägt den Namen des Features. So lassen sie sich gut zuordnen. Für die Authentifizierung prüft der Test unter anderem:

• ob das Registrierungsformular die Felder E-Mail und Passwort enthält,
• ob die Validierung von E-Mail und Passwort greift,
• ob eine bereits registrierte E-Mail-Adresse abgelehnt wird,
• Login, Session-Persistenz und Logout.

Jeder Block ist im Klartext beschrieben, sodass du nachvollziehen kannst, was geprüft wird.

Nachdem Playwright installiert war, habe ich Claude gebeten, die E2E-Tests für Feature 1 auszuführen. Dabei sind einige Fehler aufgefallen, die Claude direkt behoben hat. Am Ende waren 26 von 26 Tests grün, dazu eine Zusammenfassung der Fixes.

Tests im Browser zuschauen

Playwright läuft standardmäßig headless. Der Browser wird also im Hintergrund geöffnet, du bekommst davon nichts mit. Willst du sehen, was passiert, startest du die Tests im UI-Modus:

npx playwright test --ui

Links siehst du die Tests, rechts die Vorschau des Browsers. Nach dem Durchlauf kannst du in jeden Test hineinklicken und nachvollziehen, welche Seite aufgerufen und welche Felder geprüft wurden.

Testdateien vs. Claude per Playwright CLI testen lassen

Bisher waren die Abläufe in den E2E-Tests fest vorgegeben. Es gibt einen zweiten Ansatz: Du lässt Claude die Playwright CLI bedienen. Claude navigiert dann selbst durch die App und entscheidet, was getestet wird. Er öffnet die Anwendung, macht einen Screenshot, analysiert ihn, entscheidet, wo er als Nächstes klickt, macht wieder einen Screenshot und so weiter.

Keiner der beiden Ansätze ist besser, sie dienen unterschiedlichen Zwecken. Meine Empfehlung: Mach Testdateien für deine Kernabläufe zum festen Teil deines Entwicklungsablaufs. Exploratives Testen per CLI holst du dir in bestimmten Fällen dazu.

Was du testen solltest und was nicht

Es geht nicht um 100 Prozent Testabdeckung, das wäre Overkill. Der häufigste Fehler ist, gar nicht zu testen. Dann machen Änderungen bestehende Funktionen kaputt, und du merkst es nicht.

Immer testen:

• Business-Logik: Berechnungen, Validierungen, Regeln.
• API-Endpunkte: Kommen die richtigen Antworten zurück? Werden falsche Eingaben sauber abgefangen?
• Authentifizierung und Autorisierung: Wer darf sich anmelden, wer darf was sehen?
• Dein Kernfeature: das, wofür deine Nutzer:innen zahlen.

Nicht testen:

• rein Visuelles wie Farben und Abstände,
• Verhalten, das das Framework selbst garantiert,
• triviale Funktionen ohne eigene Logik.

Prompt: Teststrategie für dein Projekt

Auch ohne festen Ablauf mit Skills kannst du Claude eine Teststrategie für dein bestehendes Projekt erstellen lassen:

Analysiere mein Projekt und erstelle eine Teststrategie. Welche Bereiche brauchen Unit-Tests, welche Integrationstests, welche End-to-End-Tests? Priorisiere bitte nach Impact: Was würde am meisten wehtun, wenn es kaputtgeht?

Einordnung: Tests gehören in den Prozess, nicht ans Ende

Testing ist eines der trockeneren Themen, aber ein entscheidendes, wenn du mit KI ernsthaft Software entwickelst. Unit-Tests sichern einzelne Bausteine, Integrationstests die Übergänge zwischen Systemen, E2E-Tests die Abläufe, auf die es deinen Nutzer:innen ankommt. Claude Code schreibt und startet alle drei für dich, du musst nur danach fragen.

Am zuverlässigsten wird es, wenn du nicht daran denken musst. Wenn Akzeptanzkriterien schon in der Spezifikation stehen und ein fester QA-Schritt daraus Tests ableitet, wird jedes Feature automatisch geprüft. Genau das unterscheidet ein schnell gebautes Projekt von Software, die auch nach dem zwanzigsten Update noch funktioniert. Wenn du gerade erst einsteigst, fang mit meiner Anleitung an, wie du mit Claude Code deine erste Web-App entwickelst.