Testing und Werkzeuge
Testdaten
Vorbereitete Test-JSON-Datensätze für reproduzierbare Renderings verwalten
Der Bereich Testdaten speichert Ihre strukturierte JSON-Datensätze, die für Tests in Editoren reproduzierbar genutzt werden können. Je nach Einsatzzweck bildet ein Datensatz entweder den vollständigen RenderRequest inklusive request- und data-Objekt oder nur die Payload ab.
Die gespeicherten Datensätze stehen dann in Werkzeugen wie dem Template-Editor, Diagramm-Editor und QR-Code-Editor als Referenz zur Verfügung.
Diese Seite zeigt eine Liste aller Elemente, und darüber diverse Aktionen, die du ausführen kannst:
Testdaten-Liste
Die Tabelle zeigt alle gespeicherten Datensätze mit Sortierung nach ID, Name, Mandant und Zeitstempeln. Filter öffnen das Modal aus dem Header, während Spalten konfigurieren dieselben Einstellmöglichkeiten wie im Backend bereitstellt.
ID, Name
| ID | Identifier | Gruppen-Identifier | Aktiv ab | Aktiv | Wert |
|---|---|---|---|---|---|
| identifier_name | Null | Aktiv |
ID
Eindeutige Nummer zur internen Identifikation des Testdatensatzs.
Identifier
Eindeutiger Name des Testdatensatzs für Rendering und API-Aufrufe.
Eindeutiger Name für eine optionale Gruppierung von verwandten Testdatensatzn. Elemente einer Gruppe werden gemeinsam verarbeitet und optionale Validatoren können dabei einzelne Elemente aktivieren oder ignorieren.
Aktiv ab
Startdatum eines Testdatensatzs. Testdatensatzs werden erst ab diesem Datum beim Rendern beachtet.
Aktiv
Schnellübersicht, ob das Testdatensatz derzeit freigegeben ist. Deaktivierte Elemente behalten ihre Historie, werden aber nicht mehr automatisch verwendet.
Wert
Der Dateneintrag des Testdatensatzs. Kann Text, Zahlen, Bedingungen oder andere Daten enthalten, die in Vorlagen verwendet werden.
Der Name des Testdatensatzes verhält sich wie ein Identifier: er muss eindeutig sein und wird in Dropdowns oder Test-Buttons angezeigt.
Mandantenspalte
Mandanteninformationen helfen dabei, Datensätze nur für bestimmte Untermandanten (z.B. Stadtwerke oder Produktlinien) sichtbar zu machen. Ohne Zuordnung bleibt der Datensatz privat bzw. nur für den eigenen Account nutzbar.
| Umgebungs-Mandant |
|---|
| (1880) Submarke 1 |
| Null |
Zugeordneter Mandant des/der Testdatensatz. Ermöglicht Mandanten-spezifische Konfiguration.
Erstellt am, Aktualisiert am
Die Zeitstempel dokumentieren, wann Datensätze angelegt oder geändert wurden. Dadurch erkennt man zBsp., ob ein Datensatz noch zu einer aktuellen Template-Version passt oder ob er für ein Debugging aktualisiert werden sollte.
| Erstellt am | Aktualisiert am |
|---|---|
Erstellt am
Zeitstempel der Testdatensatz-Erstellung.
Aktualisiert am
Zeitstempel der letzten Änderung. Zeigt wann Testdatensatz-Konfiguration zuletzt bearbeitet wurde.
Kontext-Aktionen
Aktions-Dropdown
Aktions-Dropdown
Klicken Sie auf das Drei-Punkte-Menü am Ende jeder Zeile für Aktionen mit dem jeweiligen Testdatensatz.
Anzeigen
Öffnet eine reine Detailansicht der kompletten Meta-Informationen und Einstellungen des Testdatensatz.
Ändern
Öffnet das Bearbeitungsformular für alle Einstellungen und den Upload einer neuen Testdatensatz-Version.
Die Drei-Punkte-Menüs am Tabellenende bieten Anzeigen (schreibgeschützte Detailansicht) und Ändern (Formular öffnen). Lösch-Aktionen stehen nur Nutzern mit administrativen Rechten zur Verfügung und werden daher nicht standardmäßig eingeblendet.
Spalten konfigurieren
Passen Sie die Anzeige der Testdatensätze-Liste für bessere Übersichtlichkeit an. Spalten können per Drag-and-Drop neu angeordnet und über Checkboxen ein-/ausgeblendet werden.
Für mich anwenden : Spalten-Konfiguration wird nur für Ihren Account gespeichert und beeinflusst andere Benutzer nicht.
Als Standard anwenden : Konfiguration wird für alle Benutzer der Instanz übernommen und als neue Standard-Ansicht gesetzt.
Über die Spaltenkonfiguration lassen sich zusätzliche Felder wie subClientDefault, customId oder Validierungsinformationen ein- bzw. ausblenden. Die Aktionen Für mich anwenden, Als Standard anwenden und Auf Standard zurücksetzen entsprechen exakt dem Verhalten des Backend-Modals.
Testdaten erstellen
Beim Erstellen eines Datensatzes werden Name, optionaler Mandant und der komplette JSON-Inhalt gepflegt. Änderungen wirken sich nicht rückwirkend auf bereits ausgelöste Renderings aus, sondern nur auf zukünftige Tests.
Name & Identifier
Eindeutige Kennung für dieses/r Testdatensatz zur programmatischen Verwendung, Einbindung in Vorlagen, Lookups und API-Zugriff.
Identifiers sollten 'snake_case' sein, also klein geschrieben und Unterstriche verwenden, z.B. 'kunde_name' oder 'rechnung_nummer'.
Vergeben Sie sprechende Namen wie rechnung_demo_sondertarif. Dadurch erkennt das Team sofort, zu welchem Geschäftsfall der Datensatz gehört.
Mandantenzuordnung
Zuordnung zu einem spezifischen Umgebungs-Mandanten oder Standard-Verwendung für alle Mandanten.
Mandanten-spezifische Datensätze stellen sicher, dass z.B. vertrauliche Kundendaten eines bestimmten Stadtwerks nicht in einer anderen Umgebung auftauchen. Für globale Tests bleibt die Auswahl auf None stehen.
JSON-Inhalt
[
{
"key": "value",
"items": [1, 2, 3]
},
{
"nested": {
"property": "value"
}
}
]Pflegen Sie den kompletten RenderRequest mit request- und data-Objekt, damit Custom Mappings, Validatoren und Testdaten-Lader unverändert damit arbeiten können.
Ein vollständiger Datensatz umfasst das gesamte RenderRequest-Objekt inklusive request-Feldern wie Template, Webhook oder Kommentar sowie data mit allen Payload-Strukturen. Das erleichtert Debugging-Schritte, weil alle abhängigen Bereiche exakt denselben Input erhalten.
{
"externalId": "demo-stromabschluss",
"template": "rechnung-jahresverbrauch",
"format": "pdf",
"webhook": "billing-debug-webhook",
"comment": "Vergleichslauf Sondertarif 2025",
"emailServer": "smtp-standard",
"metadata": {
"reference": "EVU-CASE-2025-05",
"info": {}
},
"data": {
"contract": {
"internalProcessId": "84",
"tariffName": "Sondertarif E-Mobilität"
},
"invoiceNumber": "2300456",
"positions": []
}
}Nutzen Sie sprechende Payload-Werte statt Platzhaltern wie "test". Nur so erkennt man, welche Daten im Fehlerfall tatsächlich verarbeitet wurden.
Fake-Daten generieren
- Die aktuelle JSON-Eingabe wird gelesen. Ohne gültiges JSON erscheint lediglich eine Toastr-Fehlermeldung.
- Der Controller durchläuft jedes Schlüssel/Wert-Paar rekursiv (auch in Arrays) und ersetzt erkannte Schluesselwerte mit anonymisierten Werten.
- Nur erkannte Schlüssel werden ersetzt; alle anderen Werte bleiben unverändert, sodass das Backend exakt dieselbe Struktur zurückliefert.
| Key-Fragment | Beispielwert (de_DE) |
|---|---|
| firstname | Lukas |
| lastname / surname | Schneider |
| alternativeAccountHolder | Friederike Neumann |
| zip | 80333 |
| city | München |
| street | Goethestraße |
| houseNumber | 27b |
| company | Meyer Consulting GmbH |
| dateOfBirth | 1991-05-12 |
| phone / fax | +49 89 1234567 |
| l.schneider@example.de | |
| iban | DE44100110012632345678 |
| bic | DEUTDEFFXXX |
| sepaMandate | 3-598-21500-2 |
de_DE, daher enthalten alle Beispielfelder deutsche Schreibweisen.Formular-Aktionen
Aktions-Buttons zum Speichern und Verwalten der Testdatensatz-Konfiguration.
Verwenden Sie "Erstellen und weiteres Element hinzufügen" für effizientes Batch-Erstellen mehrerer Elemente.
Die Buttons Erstellen und weiteres Element hinzufügen sowie Erstellen verhalten sich wie im Backend: Erstere Option speichert den Datensatz und öffnet dasselbe Formular erneut, um mehrere Payloads hintereinander anzulegen. Der primäre Button speichert und kehrt zur Liste zurück.
Einsatz in Werkzeugen
Der Testdaten-Lader stellt die gespeicherten Datensätze in anderen Tools bereit. Damit greifen Template-Editor, Diagramm-Editor, QR-Code-Editor und der Bereich Custom Mapping testen auf denselben JSON-Stand zu und gewährleisten konsistente Ergebnisse.
Testdaten werden im Speicher verschlüsselt und stehen ausschließlich authentifizierten Benutzern der jeweiligen Instanz zur Verfügung. Für weitergehende Freigaben wenden Sie sich an support@output.rocks.
Verwandte Bereiche
- Test-Custom-Mapping: PHP-Mappings mit denselben JSON-Datensätzen prüfen.
- PDF-Overlays: Gerenderte Dokumente gegen Referenz-PDFs prüfen.
- Diagramm-Editor: Chart-Konfigurationen mit RenderRequest-Daten testen.
- QR-Code-Editor: QR-Parameter anhand gespeicherter Payloads nachvollziehen.
- Modules & Validierungen Use Case: Fachliche Hintergründe zu Templates und Testdatenszenarien.