0b4a216954
Zwei Features an derselben Stelle, die im Arbeitsverzeichnis nebeneinander lagen und sich dieselben Dateien teilen (Routen, BankingController, Bankzugang, Zugangsformular, Dokumentation) – getrennte Commits ließen sich daraus nur mit einem kaputten Zwischenstand schneiden. PayPal als zweite Art von Bankverbindung ---------------------------------------- „Bankverbindung anlegen“ führt zur Wahl der Art: HBCI/FinTS oder PayPal (bank_zugaenge.typ, Migration 014). Die Abfrage läuft über die Classic-NVP-API (Services\PaypalNvp, TransactionSearch und GetBalance). Kein Dreischritt, da PayPal genau ein Guthabenkonto führt – Zugangsdaten und Kontenzuordnung stehen in einem Formular. Konten, Umsätze, Protokoll, Regeln und Abgleich bleiben dieselben. Bankleitzahlen-Verzeichnis -------------------------- Verwaltung → Bankleitzahlen (/verwaltung/bankinstitute, Migration 015) nimmt die CSV-Institutsliste der Deutschen Kreditwirtschaft auf und beantwortet damit die eine Angabe, die beim Anlegen einer FinTS-Verbindung regelmäßig fehlt: den PIN/TAN-Zugangspunkt. Reine Nachschlagedaten ohne benutzer_id; ein Import ersetzt den gesamten Bestand, statt ihn zu ergänzen. „Nur prüfen“ und „Übernehmen“ sind zwei Knöpfe an derselben Datei – abgelegt wird sie nicht, ihr Inhalt steht ja in der Tabelle. Services\FintsInstituteImport nimmt der Datei ihre Eigenheiten ab: ISO-8859-1 statt UTF-8, ein Institutsname über zwei Zeilen in Anführungszeichen, dieselbe Bankleitzahl vielfach (eine Zeile je Filiale), Hunderte leerer Zeilen am Ende, Text statt Adresse, wo es keinen PIN/TAN-Zugang gibt. Spalten werden über ihre Überschrift angesprochen; fehlen BLZ und Institut, bricht der Import ab. Gesucht wird über Bankleitzahl, BIC, Name und Ort in einem Zug: „1822“ steht bei der 1822direkt im Namen und bei der Frankfurter Sparkasse im BIC, in keiner der beiden Bankleitzahlen. Aus der Trefferliste führt „Verbindung anlegen“ ins gefüllte FinTS-Formular. Die FinTS-Adresse ist damit kein Pflichtfeld mehr – bleibt sie leer, wird sie zur Bankleitzahl nachgeschlagen. Findet auch das nichts, weist Bankzugang den Zugang ab, statt ihn ohne Gegenstelle zu speichern. Tests: 31_PaypalZugangTest, 32_BankinstituteTest, e2e/specs/banking.spec.js, e2e/specs/bankinstitute.spec.js. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| specs | ||
| package-lock.json | ||
| package.json | ||
| playwright.config.js | ||
| README.md | ||
| run.sh | ||
E2E-Tests
Browser-Tests mit Playwright, ausgeführt über das Projekt
e2e-runner. Auf dem Host wird nichts installiert – der
Runner startet je Lauf einen frischen Container und räumt ihn danach weg.
Voraussetzungen
Die Anwendung muss vor dem Testlauf laufen und vom Host erreichbar sein:
docker compose up -d
Einmalig den Testnutzer anlegen:
docker compose exec -u www-data php php scripts/e2e-benutzer.php
Ausführen
tests/e2e/run.sh
Fehlt Docker, der Runner oder das Playwright-Image, wird mit Exit-Code 0 übersprungen statt fehlzuschlagen.
Abweichende Werte:
BASE_URL=http://host.docker.internal:8000 tests/e2e/run.sh
E2E_USER=e2e E2E_PASSWORD=geheim tests/e2e/run.sh
E2E_RUNNER_DIR=/pfad/zum/runner tests/e2e/run.sh
Lockfile
package.json pinnt @playwright/test auf die Version des Runner-Images
(aktuell 1.61.1). Das Lockfile wird ohne lokale Node-Installation erzeugt:
docker run --rm -u "$(id -u):$(id -g)" -e HOME=/tmp -v "$PWD/tests/e2e":/work -w /work \
mcr.microsoft.com/playwright:v1.61.1-noble npm install --package-lock-only
Welche Ebene wofür
Hierher gehört nur, was einen Browser braucht: Formularabläufe, Redirects,
gerenderte Views, JavaScript. Rechen- und Model-Logik gehört in die PHP-Suite
(tests/NN_*.php) – schneller und isoliert.
Berichte
HTML-Report, Screenshots und Traces landen nach einem Lauf in
playwright-report/ und test-results/ (beide nicht im Repository).