# Tests

## Ziel

Die Tests sind nach Schutzwirkung organisiert, nicht nur nach technischer Ebene.
Wichtige Architektur- und Security-Invarianten sollen schnell gezielt laufen können,
ohne dass jede Änderung immer die komplette Suite im Kopf behalten muss.

## PHPUnit-Suiten

- `CoreCore`: gesamte Test-Suite.
- `Unit`: kleine verhaltensorientierte Unit-Tests ohne breites Orchestrierungs-Setup.
- `Service`: Business-Logik, Policies, Gateways und Orchestrierungs-Tests unter `tests/Service/`.
- `Repository`: Query- und Repository-Tests unter `tests/Repository/`.
- `Domain`: fachliche Taxonomie- und Domain-Tests unter `tests/Domain/`.
- `Architecture`: alle Architektur-Contracts unter `tests/Architecture/`.
- `ArchitectureCore`: Core-Boundaries, Module-/Repository-Contracts, Taxonomie- und Sync-Contracts.
- `ArchitectureSecurity`: CSRF, PRG, File-Storage, Crypto, Logging sowie AuthZ-nahe Contracts.
- `ArchitectureUI`: UI-Contracts für Listen, Detailseiten, Runtime-Komponenten und A11y.
- `ArchitectureModules`: modulbezogene Struktur- und Isolations-Contracts.
- `ArchitectureMeta`: Agent-/Skill-/Meta-Contracts für das Repository-Setup.

## Regeln für neue Architecture-Tests

- Nur stabile Invarianten testen, keine einmaligen Migrationsdetails.
- Guards oder Risiken explizit abdecken, zum Beispiel `GR-CORE-*`, `GR-SEC-*`, `GR-TEST-*`.
- Keine Duplikate neben bereits breiten Contracts anlegen.
- String-Assertions nur verwenden, wenn kein robusterer Contract möglich ist.
- Monolithische Sammeltests vermeiden; lieber kleine thematische Contracts.

## Delete vs. Refactor vs. Keep

- `keep`: testet einen echten plattformweiten Contract oder Security-Guard.
- `refactor`: Schutz ist wichtig, aber der Test ist zu datei-, markup- oder implementation-detailnah.
- `delete`: dupliziert bestehende Schutzwirkung oder prüft nur historische Altlasten.

## Regeln für neue Service-Tests

- Services auf Guards, Orchestrierung, Normalisierung, Fehlerpfade und Seiteneffekte testen.
- Keine eigenen Tests für reine `find/list/get/set`-Delegation ohne zusaetzliche Regel.
- Thin Wrapper auf gemeinsame Primitive zentral testen, nicht pro Gateway erneut.
- Mockability-, Reflection- und Interface-Existenz-Tests ohne Risiko-Schutz vermeiden.
- Kleine Normalisierungs-Matrizen mit DataProvidern oder zusammengezogenen Contract-Dateien verdichten.

## Typische Low-Value-Muster

- Gateway-Test prüft nur `encrypt/decrypt` erneut, obwohl das Basisverhalten schon zentral abgesichert ist.
- Test bestätigt nur, dass ein Service eins zu eins an Repository oder Gateway weiterreicht.
- Test prüft nur Methodensignatur, Reflection oder dass eine Klasse mockbar ist.
- Mehrere Minidateien decken denselben Settings-/Fallback-Mechanismus mit identischem Mock-Muster ab.

## Nächste Audit-Kandidaten

- methodenweiser Low-value-Pass in `tests/Service/User/UserAccountServiceTest.php`
- methodenweiser Low-value-Pass in `tests/Service/Org/DepartmentServiceTest.php`
- methodenweiser Low-value-Pass in `tests/Service/Access/RoleServiceTest.php`
- verbleibende kleine Settings-Gateway-Tests auf weitere Verdichtung prüfen