Files
breadcrumb-the-shire/tests
fs 8cd21f3c8a fix: permission sync was deactivating core permissions, not just module-owned ones
deactivateOrphaned() treated ALL is_system=1 permissions as module-owned.
Core seed permissions (users.view, tenants.view, etc.) are also is_system=1,
so they were incorrectly deactivated — breaking admin panel access.

Fix: scan all module manifests on disk (enabled or not) to build the set of
module-owned permission keys. Only deactivate permissions whose key appears
in that set. Core seed permissions are never touched.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-19 19:32:36 +01:00
..
2026-03-04 15:56:58 +01:00
2026-02-11 19:28:12 +01:00
2026-03-04 15:56:58 +01:00
2026-03-19 19:29:45 +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.
  • 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/SecurityCryptoContractTest.php
  • tests/Architecture/AuthzApiBootstrapContractTest.php
  • tests/Architecture/ListUiSharedPartialsContractTest.php