Test-Refactorer

Das Problem

Testcode verrottet genauso wie Produktionscode. Kopierte Setup-Bloecke, unklare Testnamen, uebertriebenes Mocking und Tests, die Implementierungsdetails statt Verhalten testen, schaffen eine Wartungslast. Entwickler meiden Tests, weil die Aenderung eines Tests zehn andere bricht. Am Ende wird die Testsuite zum Hindernis beim Refactoring genau des Codes, den sie schuetzen soll.

Der Prompt

Refactore die folgende Testdatei zu mehr Wartbarkeit, Lesbarkeit und Resilienz. Die Tests sollen Implementierungsaenderungen ueberleben und dabei echte Bugs erkennen.

TESTDATEI:
[Testdatei hier einfuegen]

GETESTETE QUELLDATEI:
[Implementierung einfuegen, falls hilfreich]

Diese Refactoring-Muster anwenden:

1. **Gemeinsames Setup extrahieren** — Duplizierte Arrange-Bloecke identifizieren und in beforeEach, Factory-Funktionen oder Test-Helfer auslagern
2. **Testnamen verbessern** — Namen nach dem Muster "soll [erwartetes Verhalten] wenn [Bedingung]" umschreiben
3. **Implementierungskopplung entfernen** — Tests ersetzen, die interne Methodenaufrufe assertieren, durch Tests, die beobachtbares Verhalten/Ausgabe pruefen
4. **Uebertriebenes Mocking reduzieren** — Mocks identifizieren, die den Test bedeutungslos machen, und durch echte Implementierungen oder minimale Fakes ersetzen
5. **Eine Assertion pro Test** — Tests mit mehreren unzusammenhaengenden Assertions in separate fokussierte Tests aufteilen
6. **Fehlende Randfaelle ergaenzen** — Luecken beim Refactoring identifizieren und Tests fuer unabgedeckte Szenarien hinzufuegen

Die refactorte Testdatei mit Kommentaren zeigen, die jede Aenderung und das WARUM der Verbesserung erklaeren.

Beispielausgabe

// VORHER: Fragiler Test mit Implementierungskopplung
it('test login', () => {
  const spy = jest.spyOn(authService, 'validateToken');
  const mockDB = jest.fn().mockReturnValue({ id: 1 });
  login('user', 'pass');
  expect(spy).toHaveBeenCalledTimes(1);
});

// NACHHER: Verhaltensorientierter, resilienter Test
describe('login', () => {
  const validCredentials = createCredentials({ user: 'maria', pass: 'Stark!' });

  it('soll Session-Token zurueckgeben bei gueltigen Credentials', async () => {
    const result = await login(validCredentials);
    expect(result.token).toMatch(/^eyJ/);
    expect(result.expiresIn).toBeGreaterThan(0);
  });

  it('soll AuthError werfen bei falschem Passwort', async () => {
    const invalid = createCredentials({ user: 'maria', pass: 'falsch' });
    await expect(login(invalid)).rejects.toThrow(AuthError);
  });
});

Wann verwenden

Waehrend dedizierter Test-Wartungssprints, wenn Tests bei Refactorings haeufig brechen oder beim Onboarding neuer Entwickler, die die Testsuite verwirrend finden. Auch der richtige Schritt vor einem grossen Refactoring — zuerst Tests bereinigen, dann die Implementierung mit Zuversicht refactoren.

Profi-Tipps

• Zuerst einen Smell-Bericht anfordern — prompten: “Liste jeden Test-Smell in dieser Datei (Over-Mocking, unklare Namen, Setup-Duplikation, Implementierungskopplung) vor dem Refactoring.”
• Gleiche Abdeckung beibehalten — nach dem Refactoring sicherstellen, dass alle urspruenglichen Testfaelle noch abgedeckt sind.
• Test-Helfer schrittweise einfuehren — eine createUser()-Factory oder setupAuthenticatedSession()-Helfer extrahieren und ueber mehrere Testdateien wiederverwenden.
• Danach Mutationstesting ausfuehren — sicherstellen, dass refactorte Tests echte Bugs erkennen.