Claude Code TDD: Test-Driven Development mit KI meistern

Test-Driven Development gilt als Goldstandard der Softwareentwicklung — und als einer der häufigsten Vorsätze, die im Projektalltag auf der Strecke bleiben. Nicht weil Entwickler nicht wissen, dass Tests vor dem Code kommen sollen. Sondern weil das Schreiben von Tests für Code, der noch nicht existiert, kognitiv anspruchsvoll und zeitaufwendig ist. Man muss sich vorstellen, wie die Funktion aussehen soll, was ihre Grenzen sind, wie sie scheitern kann — bevor man auch nur eine Zeile implementiert hat.

Claude Code TDD ändert diese Gleichung. Nicht indem es den TDD-Zyklus abschafft, sondern indem es die mühsamsten Teile — Tests schreiben, Edge-Cases denken, Mocks aufbauen — erheblich beschleunigt. Der Red-Green-Refactor-Zyklus bleibt derselbe. Die Zeit, die man darin verbringt, wird deutlich kürzer.

1. Was TDD mit Claude Code bedeutet

Der klassische TDD-Zyklus besteht aus drei Schritten: Red — einen fehlschlagenden Test schreiben. Green — den minimalen Code schreiben, der den Test besteht. Refactor — den Code verbessern, ohne die Tests zu brechen. Klingt einfach. In der Praxis scheitert es oft schon am ersten Schritt.

Einen sinnvollen Test zu schreiben, bevor die Funktion existiert, erfordert, dass man das Interface der Funktion, ihre Eingaben, ihre Ausgaben und ihre Fehlerfälle bereits vollständig durchgedacht hat. Das ist echte Designarbeit — und sie kostet Zeit.

Claude Code TDD bedeutet: du beschreibst, was eine Funktion tun soll, und Claude Code schreibt den Test. Du beschreibst die Funktion, und Claude Code findet die Edge-Cases, die du vergessen hättest. Du zeigst eine Klasse, und Claude Code baut die Mocks, die du für isolierte Tests brauchst. Der Zyklus bleibt menschlich gesteuert — aber die mechanische Arbeit darin wird delegiert.

2. Den fehlschlagenden Test zuerst schreiben lassen

Der erste Schritt im TDD-Zyklus — der Red-Schritt — ist oft der schwerste. Man soll einen Test schreiben für etwas, das noch nicht existiert. Das Interface der Funktion ist noch nicht festgelegt. Die Eingaben sind noch nicht definiert. Trotzdem muss der Test spezifisch und sinnvoll sein.

Claude Code kann diesen Schritt drastisch beschleunigen. Du beschreibst das gewünschte Verhalten in natürlicher Sprache — Claude Code übersetzt das in einen konkreten, spezifischen Test:

claude "Ich möchte eine Funktion calculateDiscount(user, cart) implementieren.
Sie soll für Premium-Nutzer 15% Rabatt geben, für normale Nutzer 5%.
Bei leerem Warenkorb soll sie 0 zurückgeben.
Schreib zuerst die fehlschlagenden Tests, NICHT die Implementierung."

Claude Code schreibt daraufhin Tests, die alle beschriebenen Verhaltensweisen abdecken — inklusive Präzisierungen, die du vielleicht nicht explizit erwähnt hast: Was passiert wenn user null ist? Was wenn cart negative Mengen enthält? Was wenn der Rabatt den Gesamtpreis übersteigen würde?

// Generierte Tests — alle rot, Funktion existiert noch nicht
describe('calculateDiscount', () => {
  it('gibt 15% für Premium-Nutzer zurück', () => {
    const user = { type: 'premium' };
    const cart = { total: 100 };
    expect(calculateDiscount(user, cart)).toBe(15);
  });

  it('gibt 5% für normale Nutzer zurück', () => {
    const user = { type: 'standard' };
    const cart = { total: 100 };
    expect(calculateDiscount(user, cart)).toBe(5);
  });

  it('gibt 0 bei leerem Warenkorb zurück', () => {
    const user = { type: 'premium' };
    const cart = { total: 0 };
    expect(calculateDiscount(user, cart)).toBe(0);
  });

  it('wirft einen Fehler wenn user null ist', () => {
    expect(() => calculateDiscount(null, { total: 100 }))
      .toThrow('User darf nicht null sein');
  });
});

Diese Tests laufen sofort — und schlagen alle fehl. Das ist gewollt. Du hast jetzt eine exakte Spezifikation deiner Funktion in ausführbarem Code. Der nächste Schritt ist die Implementierung, die genau diese Tests zum Bestehen bringt.

3. Unit-Tests aus existierendem Code generieren

TDD ist ideal — aber viel Code existiert bereits ohne Tests. Refactoring ohne Tests ist riskant, Erweiterungen ohne Tests sind fehleranfällig. Claude Code kann rückwirkend Unit-Tests für bestehende Funktionen generieren, die den aktuellen Zustand des Codes dokumentieren und als Sicherheitsnetz für Änderungen dienen.

claude "Schreib vollständige Unit-Tests für die Funktion in src/utils/pricing.ts.
Decke alle erkennbaren Code-Pfade ab."

Claude Code liest die Funktion, analysiert alle Verzweigungen, Bedingungen und Rückgabepfade und schreibt Tests, die jeden Pfad abdecken. Das ist wertvoller als es klingt: bei einer Funktion mit vier if-Zweigen und zwei Fehlerbehandlungen ergeben sich schnell 8-12 Tests, die man manuell alle einzeln hätte formulieren müssen.

// Beispiel: Funktion mit mehreren Pfaden
function applyPricing(product, region, customerType) {
  if (!product || !product.basePrice) {
    throw new Error('Ungültiges Produkt');
  }
  let price = product.basePrice;
  if (region === 'EU') price *= 1.19;  // MwSt
  if (customerType === 'B2B') price *= 0.85;  // B2B-Rabatt
  return Math.round(price * 100) / 100;
}

Claude Code erkennt alle Pfade und erzeugt Tests für: gültiges Produkt in EU als B2C, gültiges Produkt in EU als B2B, gültiges Produkt außerhalb EU, ungültiges Produkt (null), Produkt ohne basePrice. Jeder Zweig im Code wird durch mindestens einen Test abgedeckt.

4. Edge-Cases automatisch identifizieren

Der häufigste Grund für Produktions-Bugs ist nicht, dass die Hauptlogik falsch ist — sondern dass ein Grenzfall nicht berücksichtigt wurde. Negative Zahlen. Leere Arrays. Null-Werte. Strings mit Sonderzeichen. Datumsangaben an Zeitzonengrenzen. Diese Fälle denkt man beim Schreiben der Funktion selten vollständig durch.

Claude Code TDD nutzt diesen Ansatz systematisch:

claude "Analysiere diese Funktion und identifiziere alle Edge-Cases,
die ich beim Testen berücksichtigen sollte. Schreib danach Tests für jeden."

// Die Funktion:
function parseUserAge(input) {
  const age = parseInt(input, 10);
  if (age < 0 || age > 150) throw new Error('Ungültiges Alter');
  return age;
}

Die von Claude Code identifizierten Edge-Cases für diese scheinbar einfache Funktion:

• Normale Fälle: valide Zahlen, Zahlen als String ("25")
• Grenzen: exakt 0, exakt 150, 1, 149
• Jenseits der Grenzen: -1, 151, -1000, 999
• Ungültige Eingaben: null, undefined, leerer String, Buchstaben, Leerzeichen, Float-Zahlen wie "25.5"
• Spezialfälle: NaN, Infinity, sehr lange Strings, Arrays

Viele dieser Fälle hätte man manuell übersehen. Claude Code findet sie systematisch, weil es nicht von einer "normalen" Nutzung ausgeht, sondern aktiv nach Kombinationen sucht, die das Verhalten der Funktion undefiniert oder überraschend machen könnten.

5. Mock-Objekte erstellen

Unit-Tests sollen Komponenten isoliert testen — ohne echte Datenbankverbindungen, ohne echte API-Calls, ohne externe Services. Das erfordert Mocks: Ersatzobjekte, die das Verhalten der echten Abhängigkeiten simulieren. Mocks zu schreiben ist mechanisch, aber zeitaufwendig — und oft fehleranfällig, weil man das Interface der gemockten Klasse exakt treffen muss.

claude "Schreib vollständige Jest-Mocks für den UserService und die
Database-Klasse, die in diesem OrderService verwendet werden.
Die Mocks sollen für Unit-Tests geeignet sein."

Claude Code liest den OrderService, identifiziert alle Methoden, die auf UserService und Database aufgerufen werden, und erstellt präzise Mocks, die genau diese Methoden implementieren:

// Generierte Mocks
const mockUserService = {
  getUserById: jest.fn(),
  updateUser: jest.fn(),
  getUserPreferences: jest.fn(),
};

const mockDatabase = {
  query: jest.fn(),
  transaction: jest.fn().mockImplementation(async (fn) => {
    return await fn(mockDatabase);
  }),
  rollback: jest.fn(),
};

// Beispiel-Setup für einen Test
beforeEach(() => {
  jest.clearAllMocks();
  mockUserService.getUserById.mockResolvedValue({
    id: '123',
    name: 'Test User',
    type: 'premium',
  });
});

// Test der OrderService-Logik, isoliert von echten Services
it('erstellt Order für Premium-Nutzer mit Rabatt', async () => {
  const service = new OrderService(mockUserService, mockDatabase);
  const order = await service.createOrder('123', cartItems);

  expect(mockUserService.getUserById).toHaveBeenCalledWith('123');
  expect(order.discount).toBe(0.15);
  expect(mockDatabase.query).toHaveBeenCalledTimes(1);
});

Der entscheidende Vorteil: Claude Code generiert Mocks, die das tatsächliche Interface der gemockten Klassen widerspiegeln — nicht ein angenommenes Interface. Es liest die Klassen im Code und baut die Mocks daraus. Wenn sich das Interface ändert, kann man Claude Code bitten, die Mocks zu aktualisieren.

6. Der vollständige TDD-Workflow mit Claude Code

In der Praxis sieht ein vollständiger Claude Code TDD-Zyklus für eine neue Funktion so aus:

1. Anforderung beschreiben: Claude Code bittet um die fehlschlagenden Tests — Verhalten in natürlicher Sprache beschreiben, Tests generieren lassen
2. Red verifizieren: Tests laufen — alle rot. Erwartetes Ergebnis.
3. Implementierung: Funktion schreiben (optional: Claude Code dabei einsetzen) bis die Tests grün sind
4. Edge-Cases prüfen: Claude Code Edge-Cases identifizieren lassen, fehlende Tests hinzufügen
5. Refactoring: Code verbessern, Tests müssen grün bleiben. Claude Code kann beim Refactoring helfen und dabei auf die Tests verweisen

Dieser Zyklus ist schneller als klassisches TDD, weil die mechanischen Teile — Tests formulieren, Edge-Cases finden, Mocks schreiben — nicht mehr allein erarbeitet werden müssen. Die konzeptuellen Entscheidungen — was soll die Funktion tun, welche Grenzen soll sie haben — bleiben beim Entwickler.

Zwei verwandte Artikel, die auf diesem Thema aufbauen:

• Claude Code Debugging — wenn Tests rot sind und der Grund unklar ist: wie Claude Code beim systematischen Debuggen hilft
• Claude Code Refactoring — den Refactor-Schritt im TDD-Zyklus mit Claude Code beschleunigen