Files
breadcrumb-the-shire/tests
fs 3f0db68b27 refactor: fix all 105 PHPStan 2 strict type findings across core and modules
Resolve all non-false-positive PHPStan 2 findings, reducing the baseline
from 486 to 382 entries (only unused-public false positives remain).

Categories fixed:
- Remove 39 redundant type checks (is_string, is_array, is_object, method_exists)
- Remove 12 no-op array_values() on already-sequential lists
- Simplify 13 null-coalesce on guaranteed offsets
- Remove 8 always-true instanceof checks
- Replace 12 redundant test assertions (assertTrue(true) → addToAssertionCount)
- Simplify 6 unnecessary nullsafe operators (?-> → ->)
- Fix 6 always-true !== '' comparisons
- Fix remaining: unset.offset, return.unusedType, staticMethod narrowing

53 files changed across core/, modules/, pages/, and tests/.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-14 12:54:20 +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