Testqualitaets-Review

Das Problem

Hohe Test-Coverage-Zahlen schaffen falsches Vertrauen. Teams jagen 80% Coverage, indem sie Tests schreiben, die Funktionen aufrufen, ohne aussagekraeftige Ergebnisse zu pruefen. Mocks ersetzen so viel vom System, dass Tests nur das Mock-Setup verifizieren. Testnamen wie “sollte funktionieren” sagen beim Fehlschlag nichts aus. Die Testsuite laeuft gruen, waehrend Bugs in Produktion gelangen, weil die Tests nichts Reales testen.

Der Prompt

Pruefe die Qualitaet des folgenden Testcodes. Handle als Test-Engineering-Lead, der bewertet, ob diese Tests tatsaechlich Bugs fangen.

TEST-FRAMEWORK: [z.B. Jest, Vitest, Pytest, Go testing]
ZU TESTENDER CODE: [Kurzbeschreibung des Testobjekts]

TEST-CODE:
[Testdateien hier einfuegen]

QUELLCODE (optional):
[Implementierung einfuegen]

Bewerte in diesen Testqualitaets-Dimensionen:

1. **Assertion-Qualitaet**
   - Pruefen Tests spezifische Ergebnisse, nicht nur "kein Fehler geworfen"?
   - Testen Assertions Verhalten, nicht Implementierungsdetails?
   - Wuerde ein subtiler Bug im Quellcode tatsaechlich einen dieser Tests fehlschlagen lassen?
   - Werden Negativfaelle getestet (ungueltige Eingabe, Fehlerbedingungen)?

2. **Coverage-Luecken**
   - Welche Randfaelle fehlen (leere Eingabe, null, Grenzwerte, grosse Eingaben)?
   - Sind Fehlerpfade getestet (Netzwerkfehler, ungueltige Daten)?

3. **Testunabhaengigkeit**
   - Kann jeder Test isoliert laufen (keine Abhaengigkeit von der Ausfuehrungsreihenfolge)?
   - Raeumen Tests nach sich auf (kein geteilter veraenderbarer Zustand)?

4. **Mock-Strategie**
   - Sind Mocks notwendig, oder wuerden Integrationstests mehr Vertrauen bieten?
   - Spiegeln Mocks das reale Abhaengigkeitsverhalten korrekt wider?
   - Ist zu viel gemockt (testet den Mock, nicht den Code)?

5. **Lesbarkeit & Benennung**
   - Beschreiben Testnamen Szenario UND erwartetes Ergebnis?
   - Wird das Arrange/Act/Assert-Pattern konsistent befolgt?
   - Kann man allein am Testnamen verstehen, was fehlgeschlagen ist?

Fuer jedes Problem liefere:
- **Test**: Welcher Testfall
- **Problem**: Warum dieser Test falsches Vertrauen gibt
- **Schweregrad**: Falsch-Positiv / Fehlende-Coverage / Fragil / Stil
- **Fix**: Verbesserter Testcode

Beispielausgabe

## Testqualitaets-Review: 4 Probleme gefunden

### Falsch-Positiv: Test prueft nichts Aussagekraeftiges
Test: "sollte einen Nutzer erstellen"
Code:
  test('sollte einen Nutzer erstellen', async () => {
    const result = await createUser({ name: 'Test' });
    expect(result).toBeTruthy();  // Besteht auch bei { error: true }
  });
Fix:
  test('erstellt Nutzer mit korrektem Namen und generierter ID', async () => {
    const result = await createUser({ name: 'Test' });
    expect(result.id).toMatch(/^usr_/);
    expect(result.name).toBe('Test');
    expect(result.createdAt).toBeInstanceOf(Date);
  });

Wann verwenden

Beim Review von Test-PRs, bei der Bewertung geerbter Testsuiten oder wenn Coverage hoch ist, aber Bugs trotzdem ausgeliefert werden. Unverzichtbar bei Vorbereitung auf ein grosses Refactoring.

Profi-Tipps

• Quellcode einbeziehen — Testqualitaet kann nur gegen die Implementierung bewertet werden. Immer beides liefern.
• Die Mutationsfrage stellen — “Wenn ich einen subtilen Off-by-one-Bug in Zeile 15 einfuehren wuerde, welcher Test wuerde es bemerken?”
• Test-zu-Code-Verhaeltnis pruefen — wenn die Testdatei 3x laenger als der Quellcode ist, ueberspezifizieren die Tests wahrscheinlich Implementierungsdetails.