# Tests

## Ziel

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

## PHPUnit-Suiten

- `CoreCore`: gesamte Test-Suite.
- `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 fuer Listen, Detailseiten, Runtime-Komponenten und A11y.
- `ArchitectureModules`: modulbezogene Struktur- und Isolations-Contracts.
- `ArchitectureMeta`: Agent-/Skill-/Meta-Contracts fuer das Repository-Setup.

## Regeln fuer 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 moeglich 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 prueft nur historische Altlasten.

## Naechste Refactor-Kandidaten

- `tests/Architecture/DetailActionPolicyContractTest.php`
- `tests/Architecture/ContainerFactoryContractTest.php`
- `tests/Architecture/SecurityLoggingContractTest.php`
- `tests/Architecture/StatusTaxonomyContractTest.php`