f388d04c05
Damit ist der geplante Funktionsumfang beisammen. Phase 4 abgeschlossen - Konfigurierbare Cockpit-Kacheln; abgewählte werden nicht berechnet - Einnahmen/Ausgaben je Monat als Balkenpaare mit Saldolinie, aufgesetzt auf den Summenbericht statt auf eine eigene Abfrage - Meine Ausgaben als Ring auf der obersten Kategorieebene - Offene Vorgänge aus allen Modulen Phase 5 – Online-Banking - nemiah/php-fints als Fork auf Codeberg, psr/log direkt eingebaut: die Anwendung hängt an keinem fremden Update-Zyklus - PIN AES-256-GCM-verschlüsselt; Schlüssel aus APP_KEY oder aus data/schluessel/app_key, den der Entrypoint einmalig erzeugt - TAN-Dialog über mehrere Requests (FinTs::persist plus serialisierte Aktion in der Sitzung) – ein wartender Prozess wäre mit php-fpm der falsche Weg - Abgleich statt Direktbuchung: verbinden, übernehmen oder verwerfen - Regeln mit vier Vergleichsarten, Betragsgrenzen und Split-Schema Phase 6 – Wertpapiere - Depotbuchung und Geldbuchung als zwei Seiten eines Geschäfts; betrag ist der Bruttowert, Nebenkosten stehen daneben - Einstand nach gleitendem Durchschnitt, realisierte Gewinne, Erträge - Kursabruf über Leeway oder FMP, täglicher Lauf per Cron - QIF-Import für !Type:Invst Dabei behoben: Der Import buchte den Geldfluss jedes Wertpapiergeschäfts als Abgang – auch bei Verkäufen und Dividenden; und er erkannte das Verrechnungskonto nicht, wenn dem Konto im L-Feld eine Kategorie vorangeht (bei Verkäufen also immer). Phase 7 – Nebenmodule und Zahlungsverkehr - Buchungsvorlagen inklusive QIF-Import, Splits werden mitskaliert - Regelmäßige Buchungen mit Fälligkeitslauf, Finanzkalender, Erinnerungen - Adressen mit IBAN-Prüfung, Verträge mit Kündigungsfrist, Sparziele - Kredite mit gerechnetem Tilgungsplan - Überweisungen über FinTS; die Buchung entsteht erst nach Annahme durch die Bank. Die pain.001-Nachricht erzeugt SepaXml selbst Nebenbei: .dockerignore ergänzt (ohne sie brach der Build an data/mariadb ab), PlatzhalterController entfernt, zwei Inline-Handler beseitigt, die die Content-Security-Policy ohnehin blockierte. 888 PHP-Prüfungen und 45 E2E-Tests grün. 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).