tdd-strictlisted

# 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 ```typescript // 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 ```typescript // 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: B