Autotest-Builder

Autotest Builder

Ziel: Tests, die nur dann fehlschlagen, wenn das Produkt kaputt ist, und die auf einen Blick erklären, warum.

Vor dem Schreiben von Code

1. Finde die bestehende Einrichtung: playwright.config.*, pytest.ini/pyproject.toml, Fixtures, Helfer, Page Objects, Testdaten. Erweitere das Vorhandene. Füge kein zweites Framework hinzu.
2. Wähle den Quellfall aus. Wenn es keinen gibt, schreibe zuerst den Fall (Schritte und erwartetes Ergebnis) in die Testbeschreibung, dann den Code.
3. Entscheide die Ebene. Verwende die günstigste Ebene, die den Fehler trotzdem abfängt:

Was du beweisen willst	Ebene
Geschäftsregel, Validierung, Berechtigungen	API-Test
Ein Benutzer kann einen Workflow in der echten UI abschließen	Ein E2E-Test pro Workflow
Rendering einer Komponente in vielen Zuständen	Komponententest, falls vorhanden
Daten haben sich wirklich geändert	API- oder DB-Prüfung nach dem UI-Schritt

Wenn das Projekt noch kein Framework hat, beginne mit Playwright Test für Web und API und pytest + requests für einen Python-Dienst. Halte den ersten Commit klein: Konfiguration, ein Fixture, ein erfolgreicher Test, ein CI-Job.

Locators

Bevorzuge in dieser Reihenfolge:

1. getByRole(role, { name }), was auch eine Barrierefreiheitsprüfung ist.
2. getByLabel, getByPlaceholder, getByText für statische Texte.
3. getByTestId, wenn das Markup nicht semantisch ist. Bitte Entwickler, data-testid hinzuzufügen, anstatt CSS-Pfade zu verwenden.

Verwende niemals XPath mit Index, automatisch generierte Klassennamen oder nth() ohne Grund in einem Kommentar.

Warten

• Verwende kein waitForTimeout oder sleep. Warte auf einen Zustand: await expect(locator).toBeVisible(), page.waitForResponse(url) oder eine Abfrage der API (expect.poll).
• Behauptungen in Playwright wiederholen sich. Verwende expect(locator) anstatt Text zu lesen und zu vergleichen.
• Wenn etwas von Natur aus langsam ist (E-Mail, Warteschlange), frage mit einem Timeout und einer klaren Nachricht ab.

Testdaten und -zustand

• Erstelle, was der Test benötigt, über die API in einem Fixture, und räume danach auf.
• Einzigartige Daten pro Durchlauf: Suffix mit einem Zeitstempel oder test.info().workerIndex.
• Melde dich einmal pro Rolle mit storageState an, nicht über die UI in jedem Test.
• Verlasse dich niemals auf die Reihenfolge zwischen Tests. Jeder Test muss allein mit --grep bestehen.

Struktur

tests/
  api/         schnelle Überprüfungen von Regeln und Berechtigungen
  e2e/         Benutzer-Workflows, wenige und wichtige
  fixtures/    Authentifizierung, Daten-Builder, API-Client
  pages/       Page-Objekte nur, wenn eine Seite von 3+ Tests verwendet wird

Benenne Tests nach Verhalten: viewer cannot delete a project, nicht test_delete_3. Ein Verhalten pro Test. Mehrere expect-Zeilen sind in Ordnung, wenn sie dieses eine Verhalten beschreiben.

Beispiele in examples/: Ein UI-Workflow mit API-Setup, ein API-Berechtigungstest und eine pytest-Version.

Drittanbieter und Seiteneffekte

Ersetze Zahlungsanbieter, E-Mail, Analysen und Karten durch page.route oder einen Test-Double, es sei denn, der Test handelt von dieser Integration. Markiere echte Integrationstests mit einem Tag (@integration), damit CI sie separat ausführen kann.

Entflacken eines Tests

1. Reproduzieren: npx playwright test <datei> --repeat-each=20 --workers=4.
2. Öffne den Trace (--trace on) eines fehlgeschlagenen Laufs und finde den ersten Schritt, der sich von einem erfolgreichen unterscheidet.
3. Übliche Ursachen: eine feste Wartezeit, ein Locator, der zwei Elemente trifft, gemeinsame Daten zwischen Workern, Animation, eine Anfrage, die nach der Behauptung abgeschlossen wird.
4. Behebe die Ursache. Wiederholungen in CI sind ein Sicherheitsnetz, keine Lösung. Markiere niemals einen Test als übersprungen ohne einen Ticket-Link im Überspringungsgrund.

Definition von fertig

• Der Test besteht allein und in der gesamten Suite, drei Läufe hintereinander.
• Du hast ihn fehlschlagen sehen: Brich die Behauptung oder den App-Zustand einmal und überprüfe, ob die Fehlermeldung sinnvoll ist.
• Keine Geheimnisse im Code. Anmeldeinformationen stammen aus Umgebungsvariablen.
• Der Testname, die Fall-ID (in einer Annotation oder einem Tag) und das erwartete Ergebnis sind im Bericht lesbar.

Berichte zurück mit: geänderte Dateien, wie man sie ausführt, was die Tests abdecken und alles, was du nicht automatisieren konntest und warum.