Files
breadcrumb-the-shire/tests
fs d06df56c49 test(security): cover tenant-scope, settings authz allow paths, auth gateways
Cluster 1 der Testabdeckungs-Initiative (.agents/runs/TEST-SEC-COVERAGE-001).
+38 Tests / +233 Assertions, nur tests/** veraendert.

- SettingsAuthorizationPolicyTest: Allow-Pfade fuer UPDATE/BRANDING_UPDATE/
  TOKENS_REVOKE/USER_LIFECYCLE_RUN plus Unknown-Ability — schliesst die
  Halb-Test-Luecke, die zuvor nur Deny-Pfade fuer 4 von 5 Abilities pruefte.
- AssignableRoleServiceTest: neu (GR-TEST-001, vorher nur transitiv via
  UserAssignmentServiceTest gedeckt).
- AuthCryptoGatewayTest: neu (Roundtrip + Fehlerpfad, GR-SEC-005).
- AuthSettingsGatewayTest: neu (Delegation zu 5 Settings-Sub-Gateways).
- UserTenantContextServiceTest: neu, 18 Tests, Tenant-Scope-Logik
  (GR-SEC-009) — current/primary/fallback, inactive-filter, assign-checks.

LdapConnectionGateway und OidcHttpGateway bleiben bewusst ohne Direkttests:
beide sind architektonische Test-Seams (dokumentiert im Docblock bzw. reiner
statischer Curl-Delegator). Ihre Logik ist ueber Konsumenten-Tests
(LdapAuthServiceTest, MicrosoftOidcServiceTest) bereits gedeckt.

Gates: QG-001 (1945 Tests) / QG-002 (PHPStan L5) / QG-003 (Architecture) /
QG-006 (php-cs-fixer) pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-22 18:57:43 +02:00
..
2026-03-19 20:22:10 +01:00

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