Modulhandbuch · Kapitel 7 von 8
Arbeitsanweisung und Testmatrix
Verbindliche Arbeitsanweisung, Mindesttestmatrix und ausführbare Nachweise.
Kapitel 7 des verbindlichen Modulhandbuchs für das Referenzmodul myInvoices.
15. Verbindliche Arbeitsanweisung
Für jedes neue oder wesentlich erweiterte datenbasierte Modul gilt:
- Fachzweck, Benutzergruppen, lesende und mutierende Routen aufschreiben.
- Beziehungen und Transaktionsgrenzen der DDs festlegen.
- DDs im direkt lesbaren dbxapp-Exportformat anlegen: TABLE, FIELDS und INDEXES mit expliziten $table[...], $field[...], $fields[]=$field, $index[...] und $indexes[]=$index; keine $addField-Closure.
- Automatische dbxDB-Systemfelder nicht im Modul nachbauen.
- Pro Formularsicht und Reportfilter eine passende FD anlegen. Jede FD besitzt strukturgleiche deutsche, englische und spanische $messages; Formulare und Reports beziehen sichtbare Fachtexte mit load_fd_messages(), get_fd_message() und format_fd_message() daraus.
- Router auf validierte Routenauswahl und Delegation begrenzen.
- Daten ausschließlich über dbxDB und DD lesen oder schreiben.
- Standard-CRUD mit dbxForm::save_post() umsetzen.
- Listen, Unterlisten, Pagination und Selection über dbxReport umsetzen.
- Callback-Defaults {fid}_{event} verwenden; nur bei bewusster Abweichung einen Callback explizit registrieren.
- Berechnete Ausgabefelder im {fid}_next_record-Callback setzen und akkumulierte Footerwerte dort spät per add_rep() aktualisieren.
- {rpt:col_count} für alle Spalten oder {rpt:colspan} für alle Spalten außer der letzten Wertespalte verwenden.
- [modul=...] für serverseitige Modul-Inclusion verwenden; keinen internen HTTP-Request bauen.
- Requestsortierung gegen feste Feld- und Richtungslisten prüfen.
- HTML in dbxTPL-Templates legen. Werte nicht pauschal escapen; nur eine tatsächlich rohe, außerhalb der dbx-Ausgabepipeline liegende Fremdeingabe wird am konkreten HTML-Kontext behandelt.
- Ajax und Confirm deklarativ über vorhandene Klassen und Attribute nutzen.
- Schreibende GETs mit dem Action-Token schützen; lesende GETs bleiben tokenlos.
- Mehrtabellenmutationen über dbxDB::begin(), commit() und rollback() atomar halten.
- Direkten Request, Inclusion, Ajax, Rechte, Summen und Mehrfachinstanzen testen.
- Doxygen, Modul-README und reale Codeverweise gemeinsam aktualisieren.
- In Deutsch, Englisch und Spanisch jeweils Formularlabels, Reportspalten, leere Zustände, Validierungs-, Erfolgs-, Fehler- und Confirmmeldungen prüfen. Gespeicherte Werte einer einsprachigen Tabelle gelten dabei als Daten und nicht als Oberflächenübersetzung.
16. Mindesttestmatrix
| Prüfung | Erwartung |
|---|---|
| Rechnungsreport direkt | korrekte Gesamt- und Trefferzahl |
| Rechnungsreport eingebettet | getrennte Modul- und DOM-Zustände |
| Positionsmarker | richtige invoice_id, keine fremden Requestwerte |
| Positions-DD ohne Recht | keine Daten trotz bekanntem Marker |
| Summenspalte | quantity * unit_price, kaufmännisch auf Cent gerundet |
| Positionsfooter | Summe aller Positionen, dynamischer colspan |
| Rechnungsfooter | Summe der sichtbaren Rechnungsseite |
| gespeicherter Snapshot | total_gross entspricht Positionsendsumme |
| Filter, Sortierung, Pagination | gleiche WHERE für Count und Select |
| Formular ohne JavaScript | normaler Submit funktioniert |
| Formular mit Ajax | nur eigenes dbxForm_{i} wird ersetzt |
| Insert und Update | DD-Rechte, Feldprüfung, automatische Systemfelder, Trace |
| Delete: „Nein“ | kein Request, keine Mutation |
| Delete: „Ja“ | Kopf und Positionen werden gemeinsam gelöscht |
| Fehler beim zweiten Delete | vollständiger Rollback |
| Delete ohne/falschen Token | keine Mutation |
| zwei Reportinstanzen | eindeutige {i}-IDs und getrennte Callback-Summen |
| SQLite/MySQL-Wechsel | kein Fachcode muss geändert werden |
| Doxygen-Build | keine fehlende Seite oder Referenz |
Ausführbare Nachweise des Referenzmoduls
Die Mindestmatrix wird durch zwei versionierte Tests und einen dokumentierten Browserablauf konkretisiert:
php dbx/modules/myInvoices/tests/myInvoices_contract_test.php
php dbx/modules/myInvoices/tests/myInvoices_integration_test.php
Der Architekturtest verbietet direkten PDO-/SQL-Zugriff, triviale dbx()-Wrapper, manuell gesetzte Auditfelder und abstrahierte DD-Feld-Closures. Er verlangt die expliziten TABLE-, FIELDS- und INDEXES-Abschnitte. Der Integrationstest prüft DD-Sync, idempotente Fixtures, automatische Systemfelder, Snapshot- und Callback-Summen, falschen Action-Token, erfolgreichen Mehrtabellen-Delete und einen erzwungenen Rollback nach dem ersten Löschschritt.
Der am 25. Juli 2026 ausgeführte Browsernachweis umfasst:
| Ablauf | Nachweis |
|---|---|
| Installations-POST | dbxForm-Ajax, zweiter Lauf meldet 3 vorhandene Fixtures |
| direkter Report | 3 Rechnungen und 3 serverseitig eingebettete Positionsreports |
| Summen | 47,30, 66,00, 129,50 EUR; Seitenfooter 242,80 EUR |
| Ajax-Insert | Erfolgsmeldung und anschließend gespeicherte RID |
| Submit ohne JavaScript | normaler HTTP-POST speichert und wechselt auf die RID |
| Confirm „Nein“ | Dialog schließt, Testrechnung bleibt vorhanden |
| falscher Token | Ablehnungsmeldung, Testrechnung bleibt vorhanden |
| Confirm „Ja“ | Kopf und Positionen verschwinden gemeinsam |
| Browserkonsole | keine Fehler oder Warnungen im finalen Reportlauf |
Der reproduzierbare Ablauf und seine stabilen Selektoren stehen in dbx/modules/myInvoices/tests/README.md.