Zum Inhalt

KI-Test-Workflow: Test Lock & TDD-First

Konzept zur späteren Umsetzung. Ziel: Verhindern dass KI Tests automatisch anpasst und dadurch Fehler unbemerkt bleiben.

Das Problem

Wenn KI Feature-Code und Tests gleichzeitig schreibt, sind Tests kein Sicherheitsnetz mehr:

KI implementiert Feature X (mit Bug Y)
KI schreibt Tests → Tests erwarten Bug Y
→ Alles grün, Fehler unsichtbar

Zusätzlich: Bricht neuer Code einen bestehenden Test, passt die KI den Test an statt den Code zu fixen.

Lösung: Zwei Regeln

Regel 1 — Test Lock (schützt Bestehendes)

Bestehende Tests sind schreibgeschützt für die KI.

  • Bricht neuer Code einen Test → Code fixen, nicht den Test
  • Test-Änderung nur auf explizite Anfrage mit Begründung

Erlaubte Gründe für Test-Änderungen: 1. Anforderung hat sich geändert (z.B. Limit von 100 → 500) 2. Test war von Anfang an falsch geschrieben (testet das Falsche) 3. Internes Refactoring ohne Verhaltensänderung (z.B. Funktion umbenannt)

Was der Entwickler angeben muss: - Welcher Test konkret (Datei + Zeile) - Warum er geändert werden soll

Ohne diese Angabe → Code fixen, nie den Test.

Regel 2 — TDD-First für neue Features (schützt Neues)

Bei neuen Features oder nicht-trivialen Bug-Fixes:

Schritt 1: KI schreibt NUR Tests (basierend auf Anforderung)
Schritt 2: Entwickler liest Tests → bestätigt oder korrigiert
Schritt 3: KI implementiert den Code
           → Tests dürfen ab jetzt nicht mehr geändert werden

Warum das funktioniert: Entwickler reviewt Verhalten, nicht Code — viel einfacher zu prüfen.

Was deckt was ab?

Szenario Regel 1 (Lock) Regel 2 (TDD)
KI macht bestehendes Feature kaputt ✅ Test bleibt rot, sichtbar —
KI schreibt Tests die nichts testen — ✅ Entwickler reviewt vor Implementierung
KI passt Test an statt Code zu fixen ✅ Verboten —
Neues Feature hat Bugs von Anfang an — ✅ Tests definieren Anforderung

Technische Absicherung via GitHub (noch nicht umgesetzt)

Zusätzlich zur KI-Workflow-Regel kann das technisch abgesichert werden:

CODEOWNERS

Datei .github/CODEOWNERS anlegen:

# Test-Dateien → alle Reviewer werden automatisch hinzugefügt
core/functions/test/**              @stefanhafner @teamMitglied2
core/apps/erp_system/test/**        @stefanhafner @teamMitglied2
core/apps/shop_system/test/**       @stefanhafner @teamMitglied2
core/shared/test/**                 @stefanhafner @teamMitglied2

Branch Protection Rule auf main

Einmal manuell in GitHub → Settings → Branches: - "Require a pull request before merging" ✅ - "Require review from Code Owners" ✅ - "Required approvals: 1" ✅

Achtung: Das verhindert auch direkte Pushes auf main für alle anderen Commits. Wenn das zu viel Overhead ist → nur die KI-Workflow-Regel nutzen (ohne Branch Protection).

einchecken-Command anpassen

Wenn einchecken erkennt dass Test-Dateien im Diff sind: - Nicht direkt pushen - Stattdessen gh pr create mit allen CODEOWNERS als Reviewer

Umsetzungsschritte (wenn bereit)

  1. copilot-instructions.md — Abschnitt "TEST LOCK & TDD-FIRST PFLICHTREGELN" einfügen
  2. .github/CODEOWNERS — anlegen mit GitHub-Benutzernamen aller Teammitglieder
  3. GitHub Settings → Branches — Branch Protection Rule auf main aktivieren (optional, nach Absprache)
  4. einchecken-Command — PR-Erstellung bei Test-Änderungen einbauen

Offene Fragen vor Umsetzung

  • Wie viele Teammitglieder? GitHub-Benutzernamen?
  • Branch Protection auf main gewünscht (alle Commits via PR) oder nur KI-Regel?