effigenix/test-automation/TASKS.md

Test Automation – Aufgaben & Phasen

Branch: experiment/test-automation Konzept: 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