106 lines
3.8 KiB
Markdown
106 lines
3.8 KiB
Markdown
---
|
||
name: testing
|
||
description: Write und ausführen von Tests für Symfony Backend (PHPUnit) und React Frontend (Jest/Vitest inkl. E2E). Deckt Unit, Functional, Integration und E2E ab – inklusive Mandantenisolation und OAuth-Flows.
|
||
license: MIT
|
||
compatibility: opencode
|
||
metadata:
|
||
audience: tester-backend-coder-frontend-coder
|
||
workflow: tdd-bdd-e2e
|
||
---
|
||
|
||
## Was ich mache
|
||
- Tests schreiben, ausführen und debuggen für das gesamte Projekt
|
||
- Test-Pyramide anwenden: Unit > Functional > Integration > E2E
|
||
- Mandantenisolation in jedem relevanten Test explizit prüfen
|
||
- OAuth-Vflows mocken und testen
|
||
- Code-Coverage messen und Lücken identifizieren
|
||
|
||
## Wann du mich nutzen solltest
|
||
- Neue Features implementiert wurden und abgedeckt werden müssen
|
||
- Tests fehlen oder veraltet sind
|
||
- Coverage-Analyse nötig ist
|
||
- CI/CD-Pipeline Tests validiert werden sollen
|
||
|
||
## Workflow
|
||
|
||
### 1. Projektstruktur prüfen
|
||
```bash
|
||
pwd # aktuellen Pfad verifizieren
|
||
ls api/phpunit.xml* api/composer.json # Symfony Test-Setup prüfen
|
||
ls frontend/package.json # Frontend Test-Setup prüfen
|
||
```
|
||
|
||
### 2. Bestehende Tests verstehen
|
||
- `api/tests/` durchsuchen für现有 Controller/Service-Tests
|
||
- `frontend/src/**/__tests__/` oder `frontend/src/**/*.test.{ts,tsx,js,jsx}` prüfen
|
||
- Tester-Agent-Konventionen aus `.opencode/agents/tester.md` beachten
|
||
|
||
### 3. Tests schreiben (Symfony PHPUnit)
|
||
```php
|
||
// api/tests/Unit/Entity/PersonTest.php
|
||
// api/tests/Functional/Controller/Api/VeranstaltungControllerTest.php
|
||
// api/tests/Integration/MandantIsolationTest.php
|
||
```
|
||
|
||
#### Wichtige Konventionen:
|
||
- `WebTestCase` für Functional Tests mit `/api/*` Routen
|
||
- Mandanten-Scope in jedem Request via Header oder Session setzen
|
||
- OAuth-Token mocken (kein echter Vonova-Flow in unit tests)
|
||
- Datenbank über `test` Environment und SQLite/In-Memory oder dedizierte Test-Datenbank
|
||
|
||
### 4. Tests schreiben (Frontend)
|
||
```bash
|
||
# Jest oder Vitest – je nachdem was konfiguriert ist
|
||
npm test --prefix frontend
|
||
# bzw.
|
||
cd frontend && npm test
|
||
```
|
||
|
||
#### Wichtige Konventionen:
|
||
- Komponenten isoliert testen (React Testing Library bevorzugt)
|
||
- API-Calls mocken (MSW, axios-mock-adapter, etc.)
|
||
- State-Management (Redux/Zustand/etc.) separat testen
|
||
- E2E über Playwright/Cypress falls vorhanden
|
||
|
||
### 5. Mandantenisolation prüfen
|
||
Jeder Test der Daten betrifft muss validieren:
|
||
- Person A aus Mandant 1 sieht NICHT Daten von Mandant 2
|
||
- API-Filters `mandantId` korrekt scopen
|
||
- Repository-Traits/QueryBuilders filtern automatisch
|
||
|
||
### 6. Tests ausführen und Coverage prüfen
|
||
```bash
|
||
# Backend
|
||
cd api && php bin/phpunit --coverage-text --testsuite=Unit
|
||
cd api && php bin/phpunit --testsuite=functional
|
||
|
||
# Frontend
|
||
cd frontend && npm test -- --coverage
|
||
|
||
# E2E (falls konfiguriert)
|
||
cd frontend && npx playwright test
|
||
# oder
|
||
cd frontend && npx cypress run
|
||
```
|
||
|
||
### 7. DeepTrace analysieren (falls Testfehler auftreten)
|
||
Wenn Tests fehlschlagen oder unerwartetes Verhalten zeigen:
|
||
- `\\opencode\deeptrace` aufrufen um die vollständige Ausführungskette zu inspecten
|
||
- Stacktrace, Umgebungsvariablen, und abhängige Aufrufe prüfen
|
||
- Besonders nützlich bei:
|
||
- Mandantenisolation-Verletzungen (wer hat welche Daten gesehen?)
|
||
- OAuth-Token-Problemen (welcher Mock wurde nicht geladen?)
|
||
- Datenbank-State-Korruption in Integrationstests
|
||
|
||
### 8. Coverage-Ziel
|
||
- Kritische Pfade > 80%: Anwesenheitsprotokollierung, Mandantenisolation, OAuth-Flows
|
||
- Lücken dokumentieren und als TODOs erfassen
|
||
|
||
## Regeln
|
||
- Immer `pwd` vor Dateioperationen prüfen
|
||
- Test-Namen klar und deskriptiv: `testPersonCreationScopesToMandant()`
|
||
- Jeder Test testet genau eine Verhalten/Anforderung
|
||
- Arrange → Act → Assert Pattern durchhalten
|
||
- Keine echten externen Calls – alles mocken (Vonova OAuth, externe APIs)
|
||
- Test-Daten sauber aufräumen ( tearDown / fixtures )
|