Files

aminovfariz 3ae289f1b7 fix(security): exclude SecurityReportTemplateService from HTML-in-service check

The service builds trusted HTML fragments exclusively for Dompdf PDF rendering,
same pattern as the existing UserAccessPdfService exclusion.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-06-23 09:31:47 +02:00

App

fix(routing): prevent login redirect loops on alias targets

2026-04-26 10:20:28 +02:00

Architecture

fix(security): exclude SecurityReportTemplateService from HTML-in-service check

2026-06-23 09:31:47 +02:00

Console

feat(console): add db:migrate CLI for idempotent core schema updates

2026-04-29 08:59:57 +02:00

Domain/Taxonomy

refactor(audit): extract audit domain into self-contained module

2026-03-25 21:12:49 +01:00

Http

fix(routing): prevent login redirect loops on alias targets

2026-04-26 10:20:28 +02:00

I18n

feat: module-owned i18n with merge-at-boot translation loading

2026-03-19 22:08:34 +01:00

Repository

refactor(tests): remove redundant tests and fix assertion style

2026-03-25 18:46:49 +01:00

Service

fix(tests): pass appTitle and appUrl to auth service constructors in tests

2026-06-05 14:51:47 +02:00

Support

refactor(action-context): remove unused fragment aggregator + building block

2026-04-26 17:34:53 +02:00

Unit

fix(flash): make flash messages one-shot per request

2026-04-15 18:45:45 +02:00

bootstrap.php

refactor: rename lib/ to core/ for clearer core-module separation

2026-04-13 23:20:42 +02:00

README.md

docs: replace ASCII umlaut fallbacks with proper äöüß across all .md

2026-04-29 09:57:22 +02:00

README.md

Tests

Ziel

Die Tests sind nach Schutzwirkung organisiert, nicht nur nach technischer Ebene. Wichtige Architektur- und Security-Invarianten sollen schnell gezielt laufen können, ohne dass jede Änderung 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 für Listen, Detailseiten, Runtime-Komponenten und A11y.
ArchitectureModules: modulbezogene Struktur- und Isolations-Contracts.
ArchitectureMeta: Agent-/Skill-/Meta-Contracts für das Repository-Setup.

Regeln für 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 möglich 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 prüft nur historische Altlasten.

Regeln für neue Service-Tests

Services auf Guards, Orchestrierung, Normalisierung, Fehlerpfade und Seiteneffekte testen.
Keine eigenen Tests für 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 prüft nur encrypt/decrypt erneut, obwohl das Basisverhalten schon zentral abgesichert ist.
Test bestätigt nur, dass ein Service eins zu eins an Repository oder Gateway weiterreicht.
Test prüft nur Methodensignatur, Reflection oder dass eine Klasse mockbar ist.
Mehrere Minidateien decken denselben Settings-/Fallback-Mechanismus mit identischem Mock-Muster ab.

Nächste 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 prüfen