39 lines
1.8 KiB
Markdown
39 lines
1.8 KiB
Markdown
# 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/ContainerFactoryContractTest.php`
|
|
- `tests/Architecture/SecurityLoggingContractTest.php`
|
|
- `tests/Architecture/StatusTaxonomyContractTest.php`
|
|
- `tests/Architecture/AuthHelpLinksContractTest.php`
|