Striktes Test-Driven Development

Dieser Skill erzwingt TDD-Praktiken basierend auf dem Kernprinzip:

"If you didn't watch the test fail, you don't know if it tests the right thing."

Wann aktivieren

• Bei jeder neuen Feature-Implementierung
• Bei Bug Fixes (erst Test der Bug reproduziert, dann Fix)
• Bei Refactoring (Tests muessen vor UND nach Aenderung bestehen)
• Bei API-Erweiterungen
• Bei jeder exportierten Funktion

Der Red-Green-Refactor Zyklus

1. RED: Test schreiben der fehlschlaegt

// ZUERST: Test schreiben
describe('calculateOEE', () => {
  it('should return 0 when availability is 0', () => {
    const result = calculateOEE({ availability: 0, performance: 100, quality: 100 });
    expect(result).toBe(0);
  });
});

// Test MUSS fehlschlagen:
// Error: calculateOEE is not defined
// ODER
// Error: Expected 0 but received undefined

Wichtig: Der Test MUSS aus dem richtigen Grund fehlschlagen:

• Funktion existiert nicht
• Funktion gibt falsches Ergebnis zurueck
• NICHT: Syntaxfehler im Test selbst

2. GREEN: Minimaler Code der Test besteht

// DANACH: Minimaler Code
export function calculateOEE(params: OEEParams): number {
  if (params.availability === 0) return 0;
  // Weitere Logik kommt spaeter durch weitere Tests
  return 0;
}

Regel: Schreibe den EINFACHSTEN Code der den Test besteht.

• Keine Optimierungen
• Keine zusaetzlichen Features
• Keine "offensichtlichen" Erweiterungen

3. REFACTOR: Bereinigen ohne neues Verhalten

// Nach mehreren gruenen Tests: Refactoring erlaubt
export function calculateOEE({ availability, performance, quality }: OEEParams): number {
  return (availability * performance * quality) / 10000;
}

Regeln fuer Refactoring:

• Alle bestehenden Tests MUESSEN bestehen bleiben
• KEIN neues Verhalten hinzufuegen
• Nur Code-Struktur verbessern
• Nach jedem Refactoring-Schritt: Tests laufen lassen

Die 13 ungueltigen Rationalisierungen

Diese Ausreden sind NIEMALS akzeptabel:

1. "Zu einfach zum Testen"

Realitaet: Einfacher Code braucht einfache Tests. 1 Zeile Test ist okay.

it('should add two numbers', () => {
  expect(add(2, 3)).toBe(5);
});

2. "Ich teste spaeter"

Realitaet: "Spaeter" bedeutet "nie". TDD bedeutet Test ZUERST.

3. "Bereits manuell getestet"

Realitaet: Manuelle Tests sind nicht reproduzierbar und skalieren nicht.

4. "Zeitdruck erlaubt keine Tests"

Realitaet: Tests sparen Zeit bei Debugging und verhindern Regressionen.

5. "Private Methoden muss man nicht testen"

Realitaet: Teste das Verhalten durch Public APIs. Wenn nicht testbar: Refactor.

6. "UI-Code kann man nicht testen"

Realitaet: React Testing Library, Playwright, Storybook existieren genau dafuer.

7. "Die Logik ist trivial"

Realitaet: Triviale Logik aendert sich. Tests dokumentieren erwartetes Verhalten.

8. "Wir haben einen QA-Prozess"

Realitaet: QA findet Bugs spaeter und teurer. TDD verhindert Bugs von Anfang an.

9. "Der Code ist nur temporaer"

Realitaet: Temporaerer Code lebt oft Jahre. Tests sichern auch temporaeren Code ab.

10. "Tests verlangsamen die Entwicklung"

Realitaet: TDD beschleunigt langfristig durch weniger Debugging und Regressionen.

11. "Legacy Code hat keine Tests"

Realitaet: Charakterisierungstests vor Aenderungen schreiben. Schrittweise verbessern.

12. "Das Framework/die Library testet das schon"

Realitaet: Teste DEINE Nutzung des Frameworks, nicht das Framework selbst.

13. "Mocking ist zu aufwaendig"

Realitaet: Wenn Mocking zu komplex ist, ist das Design zu komplex. Refactor.

Verification Checklist

Vor jedem Commit MUSS gelten:

• Jede exportierte Funktion hat mindestens einen Test
• Jeder Test ist VOR der Implementation fehlgeschlagen (RED beobachtet)
• Jeder Test prueft genau EINE Sache (Single Assertion Principle)
• Minimaler Code pro Test (kein Over-Engineering)
• Edge Cases abgedeckt:
  • Null/Undefined Inputs
  • Leere Arrays/Strings
  • Grenzwerte (0, MAX_INT, negative Zahlen)
  • Fehlerhafte Inputs (TypeError erwartet)
• Test-Namen beschreiben Verhalten: should [erwartetes Ergebnis] when [Bedingung]
• Keine skip oder only Tests im Commit
• Coverage mindestens 80% fuer neuen Code

TDD-Workflow in der Praxis

Schritt 1: Test-Datei erstellen

# Fuer neue Funktion in src/utils/oee.ts
touch src/utils/oee.test.ts

Schritt 2: Minimaler fehlschlagender Test

// src/utils/oee.test.ts
import { describe, it, expect } from 'vitest';
import { calculateOEE } from './oee';

describe('calculateOEE', () => {
  it('should return 85 for sample manufacturing data', () => {
    const result = calculateOEE({
      availability: 90,
      performance: 95,
      quality: 99
    });
    expect(result).toBeCloseTo(84.645, 2);
  });
});

Schritt 3: Test laufen lassen (MUSS fehl

...