58 lines
3.1 KiB
Markdown
58 lines
3.1 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.
|
|
- `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 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.
|
|
|
|
## Regeln fuer neue Service-Tests
|
|
|
|
- Services auf Guards, Orchestrierung, Normalisierung, Fehlerpfade und Seiteneffekte testen.
|
|
- Keine eigenen Tests fuer 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 prueft nur `encrypt/decrypt` erneut, obwohl das Basisverhalten schon zentral abgesichert ist.
|
|
- Test bestaetigt nur, dass ein Service eins zu eins an Repository oder Gateway weiterreicht.
|
|
- Test prueft nur Methodensignatur, Reflection oder dass eine Klasse mockbar ist.
|
|
- Mehrere Minidateien decken denselben Settings-/Fallback-Mechanismus mit identischem Mock-Muster ab.
|
|
|
|
## Naechste 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 pruefen
|