Files
breadcrumb-the-shire/tests
fs 157eb18610 refactor(user-lifecycle): drop redundant titles and duplicate run-now button
Cleans up two leftover redundancies after the Phase-1 cockpit
foundation landed in cc2cf3a:

* The audit-list panel embedded inside the settings page rendered
  its own "User lifecycle logs" titlebar — a redundant heading
  below the page-level titlebar that already says exactly that.
  The embedded panel now renders the filter toolbar + grid
  directly. Page-level title carries the context.
* The Run-Now action existed twice — inline in a <details>-card
  inside the form and again in the aside Quick-Actions list. The
  inline version is gone; aside is the single discoverable home
  for policy-level danger actions, consistent with how Phase 1
  introduced Purge logs there too.
* The orphan $lastRunSummary string in the action and view stays
  removed accordingly. KPI tile "Last run" still carries the
  relative-time + status hint, so no information is lost — just
  surfaced once instead of twice.

Three architecture-test lists updated to match the panel's new
shape, each with an inline comment so future readers see why the
panel is intentionally absent:
* DetailActionPolicyContractFiles.migratedConfirmFiles drops the
  user-lifecycle settings view (its danger action delegates to the
  aside-actions partial, already in this list).
* ListUiSharedPartialsContractTest.purgeTitlebarTemplateFiles drops
  the panel (no titlebar of its own anymore).
* ListTitlebarContractFiles.titlebarTemplateFiles drops the panel
  for the same reason.

All six quality gates green; behaviour-identical to a user with the
required permission (purge + run-now both still available, just
sourced from the aside).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 20:38:15 +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