851e8204e9
Budgetplaner mit Monatswerten je Kategorie, Monatsabschluss mit Prüflauf, Snapshot und Buchungssperre. Dazu drei Vorarbeiten in der Oberfläche. Budgetplaner - Migration 004: budgets, budget_positionen, monatsabschluesse - Zeilen sind der Kategoriebaum, Spalten die Monate; die ganze Tabelle wird in einem Formular gespeichert, damit mehrere Änderungen zusammen ankommen - Zwei Ansichten: Verlauf (Jahressumme, abgelaufene Monate zusammengefasst, laufender Monat mit Budget/Ist/Saldo, danach Folgemonate) und alle Monate - Ausgaben ohne Vorzeichen eingeben, es kommt aus der Kategorieart. Saldo ist Ist minus Budget: positiv heißt besser als geplant, negativ ist die Überschreitung und wird rot ausgewiesen - Übergeordnete Kategorien summieren ihre Nachfahren und sind nicht beplanbar - Ein Monat ohne Position ist "nicht geplant" und damit etwas anderes als "mit 0,00 geplant" - Wert auf Folgemonate übertragen, Budget als Kopie ins neue Jahr Monatsabschluss - Prüflauf über nicht kategorisierte Buchungen, nicht abgeglichene Umsätze und Splitsummen-Differenzen; er hält niemanden auf, sondern zeigt den Stand - Snapshot der Kontosalden und Kategoriesummen als JSON, bleibt auch nach einer Wiedereröffnung stehen - Abgeschlossene Monate sperren Buchungen in beide Richtungen: weder hinein noch heraus verschieben. Abschaltbar über monatsabschluss_sperrt_buchungen Vorarbeiten - .knopf.primaer trug einen eigenen margin-top und stand dadurch in jeder Knopfleiste tiefer als seine Nachbarn - sichtbar an "Abbrechen" neben "Konto anlegen". Der Abstand liegt jetzt allein bei der Knopfleiste - Kontengruppen werden wie Konten und Kategorien auf einer eigenen Formularseite gepflegt statt inline; dort hängt auch die Zuordnung der Konten (ankreuzen statt jedes Konto einzeln zu öffnen) - Der QIF-Export enthält keine Kontengruppen: kein Feld im !Account-Eintrag, nichts in der QSD-Datei. Import-Oberfläche und Doku sagen das jetzt - Die Baum-Einrückung lief über ein style-Attribut und wurde von der Content-Security-Policy verworfen; sie steht jetzt als data-ebene im Markup. Aus demselben Grund blendete app.js Erfolgsmeldungen nie aus Tests: 11_BudgetTest, 12_MonatsabschlussTest (76 Prüfungen), E2E planung.spec.js. Einzelheiten in docs/planung.md. 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).