Zum Hauptinhalt springen

Syncanto Integration- und E2E-Teststrategie

Syncanto Integration- und E2E-Teststrategie

Ziel​

Syncanto soll vor dem Launch nicht nur hohe Code Coverage erreichen, sondern die fachlich wichtigsten Abläufe als echte Integrations- und End-to-End-Flows absichern. Code Coverage ist ein Diagnosewerkzeug; ein grüner E2E-Test soll dagegen beweisen, dass ein Nutzer einen kompletten Anwendungsfall über die reale Oberfläche und die realen HTTP-Endpunkte erfolgreich durchführen kann.

Testpyramide für Syncanto​

1. Feature-/Integrationstests mit Pest​

Diese Tests laufen innerhalb von Laravel und verwenden echte Models, Policies, Services, Livewire-Komponenten, Datenbank und HTTP-Routen. Externe Systeme werden nur an ihrer Netzwerkgrenze ersetzt.

Priorität:

  • Mandanten- und Objektgrenzen
  • Policies und scoped Responsibilities
  • Livewire-Mutationen
  • API-Endpunkte
  • Jobs, Commands und Services mit echter DB-Wirkung
  • Domain Events
  • Datei-/Storage-Flows mit Fake Storage, sofern keine native Infrastruktur erforderlich ist

Nicht künstlich auf 100 Prozent bringen:

  • reine Blade-Darstellung
  • Framework-Glue
  • native Bild-/PDF-Pipelines, wenn ein Mock den eigentlichen Fehler nicht erkennen könnte

2. Browser-E2E mit Playwright​

Für Browser-E2E ist Playwright das Zielwerkzeug. Gründe:

  • Chromium als echter Browser
  • Desktop- und Mobile-Viewports
  • gute Unterstützung für Livewire/Alpine
  • Screenshots, Videos und Traces bei Fehlern
  • API-Aufrufe im selben Test möglich
  • parallele Ausführung in GitHub Actions

Playwright wird erst als Dependency ergänzt, wenn package.json und package-lock.json gemeinsam aktualisiert werden können. Keine Änderung nur an package.json über GitHub.

3. Infrastruktur-Integrationstests​

Einige produktive Pfade brauchen echte native Infrastruktur und sollen nicht durch Mocks schön gerechnet werden. Dafür werden separate CI-Integrationstests vorgesehen.

Beispiele:

  • ConcertPrintRenderer: GD + Imagick + CMYK + DomPDF
  • Mail-/Queue-Flows
  • Redis-Queue
  • externe KI-Provider über einen kontrollierten Testadapter oder Contract-Test
  • später S3/Objektspeicher, falls produktiv relevant

Deterministische E2E-Testdaten​

Browser-E2E darf nicht vom normalen DatabaseSeeder oder zufälligen Faker-Daten abhängen. Dafür existiert Database\Seeders\E2eSeeder mit festen, lesbaren Daten.

Ausführung auf einer vorbereiteten lokalen/Test-Datenbank:

php artisan db:seed --class=Database\\Seeders\\E2eSeeder

Der Seeder ist idempotent und bricht außerhalb der Umgebungen testing und local absichtlich ab.

Testidentitäten, gemeinsames Passwort syncanto-e2e:

  • admin@e2e.syncanto.test: vollständige Konzertverwaltung
  • member@e2e.syncanto.test: normales aktives Mitglied
  • setlist@e2e.syncanto.test: nur Responsibility concert.setlist
  • marketing@e2e.syncanto.test: Marketing-Responsibilities für Plan, Social, Sharepics, Print und Website
  • foreign@e2e.syncanto.test: anderer Mandant

Feste Testdaten:

  • Mandant E2E Chor Aachen
  • zweiter Mandant E2E Fremdchor
  • E2E Konzerthalle Aachen
  • Songs E2E Eröffnung und E2E Finale
  • E2E Bestehendes Konzert für Edit-/Responsibility-Flows
  • E2E Fremdes Konzert für Mandantentrennung

Die Korrektheit und Idempotenz des Seeders wird selbst durch tests/Feature/E2eSeederTest.php geprüft.

Erste verpflichtende Konzert-E2E-Flows​

E2E-CONCERT-01 Konzert anlegen und öffnen​

  1. Admin meldet sich an.
  2. Öffnet Kalender oder Konzertübersicht.
  3. Legt ein Konzert mit Titel, Start, Ende und Ort an.
  4. Fügt Songs zur Setlist hinzu.
  5. Speichert.
  6. Öffnet die Konzertdetailseite erneut.
  7. Prüft Titel, Termin, Ort und Setlist.

Beweist: Routing, Livewire Create, Validierung, DB, Domain-Flow und Detailansicht funktionieren zusammen.

Laravel-Vorläufer: tests/Feature/Concerts/ConcertWorkflowIntegrationTest.php.

E2E-CONCERT-02 Scoped Responsibility darf exakt einen Bereich bearbeiten​

  1. Admin weist setlist@e2e.syncanto.test für ein konkretes Konzert concert.setlist zu.
  2. Setlist-Nutzer meldet sich an.
  3. Öffnet dieses Konzert.
  4. Fügt einen Song hinzu und sortiert die Setlist.
  5. Versucht Datum, Ort oder Marketing zu ändern.
  6. Diese Aktionen dürfen nicht verfügbar sein bzw. müssen serverseitig scheitern.
  7. Öffnet ein zweites Konzert ohne Responsibility; dort darf keine Setlist-Mutation möglich sein.

Beweist: UI und serverseitige Policy stimmen überein; Responsibility ist objekt- und bereichsgebunden.

Laravel-Vorläufer: tests/Feature/Concerts/ConcertWorkflowIntegrationTest.php.

E2E-CONCERT-03 Konzertmarketing bis öffentliche Seite​

  1. Marketing-berechtigter Nutzer öffnet ein Konzert.
  2. Wählt bzw. bestätigt das Konzertdesign.
  3. Pflegt Marketingtexte.
  4. Aktiviert die öffentliche Konzertseite.
  5. Öffnet die öffentliche URL in einem neuen Browser-Kontext ohne Login.
  6. Prüft Titel, Termin, Ort und öffentliche Inhalte.

Beweist: Admin-Web → Marketingdaten → öffentlicher HTTP-Pfad funktioniert vollständig.

Laravel-Vorläufer: tests/Feature/Concerts/PublicConcertWorkflowIntegrationTest.php.

E2E-CONCERT-04 Share-Aufgabe Web/API​

  1. Admin aktiviert eine Share-Kampagne für ein Konzert mit gerendertem Story-Sharepic.
  2. Mitglied ruft das App-Dashboard per API auf.
  3. share_tasks enthält die Aufgabe.
  4. Bildendpoint liefert das Bild nur für den zugewiesenen Nutzer.
  5. Nutzer markiert die Aufgabe als geteilt oder übersprungen.
  6. Dashboard liefert die Aufgabe danach nicht erneut.

Beweist: Web-Konfiguration → Service → Assignment → API → Statusmutation.

Laravel-Vorläufer: tests/Feature/Concerts/ShareCampaignWebApiIntegrationTest.php.

E2E-CONCERT-05 Print-Verteilung Web/API​

  1. Print-Verantwortlicher plant Orte und Verteiler.
  2. Mitglied ruft /api/distribution-tasks auf.
  3. Richtige Route und Reihenfolge erscheinen.
  4. Mitglied meldet einen Stop als erledigt.
  5. Web-Verteilübersicht zeigt den neuen Status.
  6. Fremder Nutzer/Mandant kann das Target nicht verändern.

Beweist: Web-Planung und App-Verteilung greifen auf dieselbe Fachlogik zu.

Laravel-Vorläufer: tests/Feature/Concerts/PrintDistributionWebApiIntegrationTest.php.

E2E-CONCERT-06 Mandantentrennung​

  1. Nutzer aus Mandant A ist eingeloggt.
  2. Direkter Aufruf bekannter IDs/URLs aus Mandant B für Konzert, Song, Sharepic, Todo, MarketingTarget und Technikobjekte.
  3. Alle Zugriffe enden als 403/404 entsprechend der jeweiligen Ressourcenstrategie.
  4. Keine Mutation in Mandant B.

Dieser Flow ist ein Release-Blocker.

Teile dieses Flows sind bereits in den Konzert-Featuretests für Policies, Todos, Share-Tasks, Distribution-Tasks, Technikplan, Cuelist und Planlisten vorhanden. Playwright soll daraus später einen zusammenhängenden Browser-Security-Flow machen.

Weitere E2E-Flows vor Launch​

  • Konzertteilnahme inkl. pausiertem Mitglied und pause_override
  • Eltern-/verwaltete Nutzer Teilnahme
  • Moderation generieren mit kontrolliertem Fake-AI-Provider
  • GEMA-Daten pflegen und Export herunterladen
  • Cuelist/Technikplan
  • Konzert löschen und Rückkehr zur Übersicht
  • Mobile Viewport für Mitgliederpfade
  • Fehlerdarstellung bei abgebrochenen API-/Livewire-Requests

GitHub-Actions-Zielbild​

Später eigener Job e2e:

  1. Checkout
  2. PHP 8.5 + benötigte Extensions
  3. Composer Install
  4. Node Install
  5. Frontend Build
  6. Playwright Browser installieren
  7. separate SQLite-Datei oder MySQL-Service vorbereiten
  8. Migration + Database\Seeders\E2eSeeder ausführen
  9. Laravel-Testserver starten
  10. Playwright ausführen
  11. bei Fehlern Trace/Screenshot/Video als GitHub-Artifact hochladen

Browser-E2E sollte nicht :memory: SQLite verwenden, weil Laravel-Server und Playwright in getrennten Prozessen laufen. Eine echte SQLite-Datei oder ein MySQL-Service ist erforderlich.

Release-Gates​

Vor Launch sollten mindestens folgende Gates gelten:

  • alle Pest Feature-/Integrationstests grün
  • API-Kernbereiche 100 Prozent Coverage, soweit sinnvoll und ohne Framework-/Native-Glue zu erzwingen
  • alle Security-/Mandantentrennungs-E2E-Flows grün
  • alle sechs Konzert-E2E-Kernflüsse grün
  • Browser-Trace wird bei jedem E2E-Fehler gespeichert
  • native Renderer haben einen eigenen Infrastrukturtest statt künstlicher Mock-Coverage

Grundregel​

Ein Test soll einen Fehler verhindern, den ein echter Nutzer oder Angreifer auslösen könnte. Tests werden nicht allein geschrieben, um eine Coverage-Zahl zu erhöhen.