https://github.com/krll-dev/playwright-e2e
https://github.com/krll-dev/playwright-e2e
Last synced: 19 days ago
JSON representation
- Host: GitHub
- URL: https://github.com/krll-dev/playwright-e2e
- Owner: krll-dev
- Created: 2026-07-05T07:01:35.000Z (23 days ago)
- Default Branch: main
- Last Pushed: 2026-07-05T13:30:26.000Z (23 days ago)
- Last Synced: 2026-07-05T14:14:16.701Z (23 days ago)
- Language: Java
- Size: 28.3 KB
- Stars: 0
- Watchers: 0
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# playwright-e2e
E2E-Testautomatisierung mit **Playwright (Java)**, **JUnit 5** und **Allure** –
inklusive eigener **Bestand-Mini-App** (Sparten **KFZ** & **Unfall**) als
Zielsystem. Architektur und Konventionen: [`CLAUDE.MD`](CLAUDE.MD).
## Aufbau
Ein Maven-Projekt, zwei Teile:
- **`src/main/` – Bestand-Mini-App**: kleines Bestandssystem mit Login, Suche,
Schnellerfassung KFZ/Unfall (drei Unfall-Varianten: Einzelunfall,
Gruppenunfall mit/ohne Namensnennung), Bearbeitungsmasken und REST-Anlage.
Reines JDK (`com.sun.net.httpserver`) + Gson, alles **in-memory** (keine DB).
- **`src/test/` – E2E-Tests** nach komponentenbasiertem POM:
```
tests → flow/ → page/ → component/ (asserten → orchestrieren → agieren)
data/ Records + sealed Interfaces (UnfallVariante, Bearbeitung)
rest/ BestandRestClient (Testdaten-Vorbedingungen per POST /api/vertraege)
context/ TestContext-Record (Page + BrowserContext + APIRequestContext, pro Test frisch)
```
> **Neu Tests schreiben?** Der Praxisleitfaden
> [`docs/tests-schreiben.md`](docs/tests-schreiben.md) zeigt mit kurzen
> Beispielen, wie man die verschiedenen Testarten schreibt (Sammel-Annotationen,
> parametrisierte Tests, `@AsUser`, Zustand über Felder, REST, Testgruppen,
> Flow/Page/Component).
Kernideen:
- **Statelessness**: `TestContext` wird pro Test erzeugt und per
Konstruktor-Injektion an Flows gereicht; nichts überlebt den Test.
- **Sealed Interfaces + exhaustives `switch`** (JDK 21): die drei
Unfall-Varianten und die Bearbeitungsoperationen sind Daten – neue Variante =
neuer Record + ein `case`, der Compiler erzwingt Vollständigkeit.
- **Verkettbare Edits**: `BearbeitungFlow.fuehreAus(List.of(new ZahlwegAendern(…),
new NeuePersonHinzufuegen(…), …))`.
- **Custom `PlaywrightExtension`**: startet die App in-process, hält Playwright
je Worker-Thread (parallele Testklassen), Video pro Test, Trace bei Fehler,
Login-State pro Nutzer (`@AsUser`), alles an Allure angehängt.
## Lokal ausführen
```bash
# Tests (App startet automatisch in-process; braucht Google Chrome)
mvn test
# Ohne installiertes Chrome: gebündeltes Playwright-Chromium
mvn test -Dbrowser.channel=
# App standalone starten (http://localhost:8080, Login: admin/geheim2)
mvn compile exec:java
```
### Langlaufende Tests (On-Demand-Gruppen)
Langlaufende Tests werden per JUnit-`@Tag` markiert und laufen **standardmäßig
nicht** mit. Es gibt drei vorbereitete Gruppen – `@Slow`, `@Nightly`, `@Load`
(in `src/test/java/dev/krll/e2e/config/`), setzbar auf Klasse oder Methode und
orthogonal zu `@CoreTest`/`@KfzTest`/`@UnfallTest`.
```bash
mvn test # Standard: On-Demand-Gruppen ausgeschlossen (schnell)
mvn test -Pslow # nur @Slow-Tests
mvn test -Pnightly # nur @Nightly-Tests
mvn test -Pload # nur @Load-Tests
# Mehrere Gruppen zugleich (Tag-Expression):
mvn test -Dtest.groups="slow | nightly" -Dtest.excludedGroups=
# Wirklich alles inkl. On-Demand:
mvn test -Dtest.excludedGroups=
```
Neue Gruppe anlegen: kleine `@Tag("…")`-Annotation nach dem Muster von
`Slow.java` hinzufügen, den Tag in `test.excludedGroups` (in der `pom.xml`)
aufnehmen und optional ein gleichnamiges Profil ergänzen. Details in
[`CLAUDE.MD`](CLAUDE.MD#langlaufende-tests-on-demand-gruppen).
Alle Werte (URLs, Credentials, Browser) sind System-Properties mit Defaults im
``-Block der `pom.xml` – Details in
[`CLAUDE.MD`](CLAUDE.MD#konfiguration--ausführung).
Allure-Report:
```bash
mvn allure:report # -> target/site/allure-maven-plugin
mvn allure:serve # Report direkt im Browser öffnen
```
## Code-Stil
Einheitliche Formatierung über **[Spotless](https://github.com/diffplug/spotless)**
mit **[Palantir Java Format](https://github.com/palantir/palantir-java-format)**
(konfiguriert in der [`pom.xml`](pom.xml)):
```bash
mvn spotless:apply # Code formatieren
mvn spotless:check # nur prüfen (bricht bei Verstößen ab; läuft auch in CI)
```
Durchsetzung auf zwei Ebenen:
- **CI-Gate**: `mvn spotless:check` läuft als eigener Schritt im Workflow und
blockiert Pull Requests bei Formatverstößen.
- **Git-Hook** (`.githooks/pre-commit`): formatiert gestagte `.java`-Dateien
automatisch vor jedem Commit. **Einmalig pro Klon aktivieren:**
```bash
git config core.hooksPath .githooks
```
> Hinweis: Der Formatter benötigt unter JDK 21 die `add-exports`/`add-opens`-Flags
> aus [`.mvn/jvm.config`](.mvn/jvm.config) – diese Datei ist eingecheckt und wird
> von Maven automatisch geladen.
## CI/CD
Der Workflow [`.github/workflows/e2e.yml`](.github/workflows/e2e.yml) läuft bei
jedem Push und Pull Request:
1. JDK 21 + Google Chrome (stable) einrichten,
2. **Code-Stil prüfen** (`mvn -B spotless:check`),
3. **Smoke-Test**: Bestand-Mini-App standalone starten und `/health` prüfen,
4. E2E-Tests ausführen (`mvn -B test` – die App läuft dabei in-process),
5. Allure-Report erzeugen (`mvn -B allure:report`),
6. Report bei Pushes auf **GitHub Pages** veröffentlichen:
**https://krll-dev.github.io/playwright-e2e/**
Push-/PR-Läufe bleiben schnell (On-Demand-Gruppen ausgeschlossen). Eine Gruppe
gezielt in CI laufen lassen: Workflow **manuell** über „Run workflow" starten und
im Feld `groups` z. B. `slow` eintragen (leer = Standardlauf).
### GitHub Pages (einmalige Einrichtung)
> **Repo → Settings → Pages → Build and deployment → Source: „GitHub Actions"**