init e2e ui tests base skeleton

test-automation/TASKS.md

@@ -0,0 +1,96 @@
+# Test Automation – Aufgaben & Phasen
+
+Branch: `experiment/test-automation`
+Konzept: [`docs/ui-testing-automation.md`](./docs/ui-testing-automation.md)
+
+> **Merge-Regel:** Kein Merge in `main` ohne ausdrückliche menschliche Bestätigung.
+
+---
+
+## Phase 0 – TUI-Tests ausbauen
+
+> Sofort umsetzbar, kein neues Setup nötig. Nutzt `ink-testing-library` + `vitest`.
+> Ort: `frontend/apps/cli/src/__tests__/screens/`
+
+- [ ] `__tests__/screens/` Verzeichnisstruktur anlegen (`masterdata/`, `production/`)
+- [ ] `SupplierForm.test.tsx` – TC-SUP-01 (Pflichtfelder), TC-SUP-02, TC-SUP-03 (leerer Name)
+- [ ] `CategoryForm.test.tsx` – TC-CAT-01 (Happy Path), TC-CAT-04 (Duplikat), TC-CAT-06 (leerer Name)
+- [ ] `SupplierList.test.tsx` – TC-SUP-06 (Filter/Suche)
+- [ ] Bestehende 4 Tests (`ConfirmDialog`, `ErrorDisplay`, `SuccessDisplay`, `useRoles`) als Vorlage prüfen
+- [ ] Alle neuen TUI-Tests laufen durch (`pnpm --filter @effigenix/cli test`)
+
+---
+
+## Phase 1 – API E2E Grundgerüst
+
+> Playwright-Setup in `test-automation/web-ui/`. API-Tests ohne Browser.
+
+- [ ] `web-ui/package.json` finalisieren (Abhängigkeiten prüfen, ggf. pnpm workspace eintragen)
+- [ ] `web-ui/playwright.config.ts` validieren und anpassen
+- [ ] `web-ui/fixtures/auth.fixture.ts` implementieren und testen
+- [ ] `web-ui/fixtures/seed.fixture.ts` implementieren (DB-Reset-Strategie klären)
+- [ ] `web-ui/helpers/api-client.ts` typisiert implementieren
+- [ ] Backend `Dockerfile` erstellen (test-Profil, mit Seed-Daten)
+- [ ] `docker-compose.e2e.yml` validieren (DB → Backend → e2e-runner Healthchecks)
+- [ ] `web-ui/Dockerfile` validieren
+- [ ] Erste Spec: `tests/api/masterdata/categories.spec.ts` (TC-CAT, Issue #62)
+- [ ] Erste Spec: `tests/api/masterdata/suppliers.spec.ts` (TC-SUP, Issue #63)
+- [ ] End-to-end-Run lokal erfolgreich: `docker compose -f test-automation/docker-compose.e2e.yml up`
+- [ ] `just test-e2e` Recipe im `justfile` ergänzen
+
+---
+
+## Phase 2 – Vollständige API-Coverage
+
+> Alle manual-testing Issues und Feature-Stories als Playwright-Specs.
+
+- [ ] `tests/api/masterdata/customers.spec.ts` – TC-CUS, Issue #65
+- [ ] `tests/api/masterdata/contracts.spec.ts` – TC-B2B, Issue #66
+- [ ] `tests/api/masterdata/articles.spec.ts` – TC-ART, Issue #64
+- [ ] `tests/api/auth/authorization.spec.ts` – TC-AUTH, Issue #67
+- [ ] `tests/api/production/orders.spec.ts` – US-P13–P17, Issues #38–#42
+- [ ] `tests/api/production/batches.spec.ts` – US-P09–P12, Issues #33–#36
+- [ ] `tests/api/production/recipes.spec.ts` – US-P02–P08, Issues #26–#32
+- [ ] `tests/api/production/traceability.spec.ts` – US-P18–P19, Issues #43–#44
+- [ ] `tests/api/inventory/stock.spec.ts` – Story 2.x–6.x, Issues #4–#20
+- [ ] `tests/api/inventory/movements.spec.ts`
+- [ ] `tests/api/inventory/reservations.spec.ts`
+- [ ] Test-Generierungs-Skript (`scripts/generate-tests-from-issue.ts`) finalisieren
+- [ ] Skript in `justfile` als `just generate-test <issue-nr>` integrieren
+- [ ] Alle Specs im Docker-Stack grün
+
+---
+
+## Phase 3 – CI/CD Integration
+
+> GitHub Actions Workflow für automatische Test-Ausführung.
+
+- [ ] `.github/workflows/e2e.yml` erstellen
+- [ ] Trigger: Push auf `main`, PRs gegen `main`
+- [ ] JUnit-Report als CI-Artefakt hochladen
+- [ ] Playwright HTML-Report als GitHub Pages veröffentlichen (optional)
+- [ ] Badge in README einbinden
+
+---
+
+## Phase 4 – Web UI Tests (Browser)
+
+> Erst sinnvoll, wenn `apps/web` ausgebaut ist. Platzhalter bereits vorhanden.
+
+- [ ] Browser-Projekt in `playwright.config.ts` aktivieren (`web-chromium`)
+- [ ] Page Object Models für Web-App-Seiten anlegen
+- [ ] Login-Flow als Browser-Test
+- [ ] Erste Screen-Tests (analog zu TUI-Tests in Phase 0)
+- [ ] Visuelle Regression via Playwright Screenshots (optional)
+
+---
+
+## Offene Punkte & Entscheidungen
+
+| Punkt | Status | Massnahme |
+|---|---|---|
+| Backend `Dockerfile` | Fehlt | In Phase 1 erstellen |
+| Seed-Testdaten Isolation | Offen | Strategie in Phase 1 klären (DB-Reset vor Suite oder pro Test) |
+| `gh` Token `read:project` Scope | Fehlt | `gh auth refresh -s read:project` ausführen wenn nötig |
+| TUI-Tests Abgrenzung | Klar | Vitest + ink-testing-library, gemockte API-Calls |
+| Scanner (Tauri/mobil) | Out of scope | Separates Konzept, ggf. `test-automation/scanner/` später |