# 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/`

- [x] `__tests__/screens/` Verzeichnisstruktur anlegen (`masterdata/`, `production/`)
- [x] `SupplierForm.test.tsx` – TC-SUP-01 (Pflichtfelder), TC-SUP-02, TC-SUP-03 (leerer Name)
- [x] `CategoryForm.test.tsx` – TC-CAT-01 (Happy Path), TC-CAT-04 (Duplikat), TC-CAT-06 (leerer Name)
- [x] `SupplierList.test.tsx` – TC-SUP-06 (Filter/Suche)
- [x] Bestehende 4 Tests (`ConfirmDialog`, `ErrorDisplay`, `SuccessDisplay`, `useRoles`) als Vorlage prüfen
- [x] 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 |