Files
breadcrumb-the-shire/tests
fs 811588290c feat(core): detail drawer + address book list redesign
Introduces a reusable core detail-drawer primitive that slides in from the
right and loads any view via a `*-fragment(none).phtml` endpoint. Bundles the
address book list overhaul that is its first consumer.

Core additions:
- `app-detail-drawer.js` — generic drawer with stepper, focus trap, body
  scroll-lock, URL-hash deep-linking, session-expiry detection
- `app-fragment-init.js` — auto-wires tabs/lookups/confirm/file-upload/
  fslightbox inside injected HTML; consumers do not re-initialize components
- `app-focus-trap.js` — shared focus-trap + refcounted scroll-lock, used by
  both filter-drawer and detail-drawer
- `getHtml()` in `app-http.js` + `SessionExpiredError`; drawer reloads the
  page on auth redirect instead of rendering the login form in the panel
- `DetailDrawerFragmentContractTest` enforces that every `initDetailDrawer`
  consumer ships matching `*-fragment($id).php` + `*-fragment(none).phtml`

Address book list:
- Grid collapses from 9 columns to 4 (identity / context / phone / actions)
  with a two-line identity cell (avatar + name + email)
- Tenant register tabs above the grid using the `app-list-tabs` partial;
  tenant filter wired via hidden toolbar field so grid.js forwards it on
  every data fetch
- Profile body extracted to a shared partial so the full-page view and the
  new drawer fragment share the same markup
- New i18n keys for the drawer/list labels

Also refactors `app-filter-drawer` to reuse the shared focus-trap and
scroll-lock instead of maintaining its own copy, and documents the
detail-drawer convention in CLAUDE.md.

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