So erstellen Sie synthetische Testdatensätze für einen Workflow
Erstellen Sie eine kleine Menge erfundener Datensätze, vielleicht zehn bis zwanzig, die gezielt den Normalfall, die heiklen Grenzfälle, ungültige Eingaben und Duplikate enthält, und geben Sie jedem Datensatz eine schlichte Bezeichnung, was er testet. Lassen Sie den Workflow über diese Menge laufen, vergleichen Sie die Ergebnisse mit den vorher notierten Resultaten und halten Sie echte Kundendaten aus den ersten Runden heraus.
Warum die Daten erfinden
Beim Testen mit Live-Datensätzen kann ein Fehler eine echte Kundin oder einen echten Kunden anschreiben oder eine echte Bestellung verändern. Die n8n-Dokumentation beschreibt Data Mocking als das Erstellen oder Simulieren von Testdaten ohne Verbindung zu echten Quellen und sagt, dass Pinning und Mocking helfen, Live-Systeme vor wiederholten Testaufrufen zu schützen. Wenn Sie die Daten selbst erfinden, können Sie außerdem Fälle einbauen, die selten vorkommen, aber wehtun würden, wenn sie eintreten.
Wählen Sie die Fälle gezielt
Kopieren Sie nicht einen zufälligen Ausschnitt des letzten Monats. Legen Sie fest, was der Workflow in jeder Situation tun soll, und erfinden Sie für jede einen Datensatz. Eine nützliche Ausgangsmenge sieht so aus:
- Ein normaler Datensatz, der direkt durchlaufen sollte
- Ein Datensatz an jeder Grenze, etwa die kleinste und die größte zulässige Menge
- Ein Datensatz mit einem fehlenden Pflichtfeld
- Ein Datensatz mit unerwartetem Format, etwa einem anders geschriebenen Datum oder einem Namen mit Akzent
- Ein Duplikat eines früheren Datensatzes, zweimal gesendet
- Ein Datensatz, der zur Entscheidung an eine Person gehen soll, statt automatisch bearbeitet zu werden
- Ein sehr langes oder leeres Textfeld
Schreiben Sie zuerst das erwartete Ergebnis
Schreiben Sie zu jedem erfundenen Datensatz auf, was geschehen soll, bevor Sie irgendetwas ausführen: welchen Weg er nimmt, welche Nachricht gesendet wird, was gespeichert und was abgelehnt wird. Ohne diese Notiz lesen Sie die Ausgabe und befinden, sie sehe richtig aus, was ein schwächerer Test ist als der Vergleich mit einer Antwort, auf die Sie sich vorher festgelegt haben.
Eingaben mocken oder pinnen
n8n unterscheidet zwei Konzepte. Mocking erzeugt Testdaten, zum Beispiel mit den Knoten Code oder Edit Fields. Pinning speichert Daten, ob gemockt oder echt, und verwendet sie in späteren Ausführungen wieder, statt frische Daten abzurufen. Es erlaubt auch, gepinnte Daten zu bearbeiten, um verschiedene Szenarien zu prüfen, ohne jedes aus dem externen System senden zu müssen. Die Dokumentation sagt, dies seien Entwicklungsfunktionen: Pinning ist für Produktionsausführungen nicht verfügbar. Welches Werkzeug Sie auch nutzen, halten Sie Testeingaben vom Live-Setup getrennt, damit Testdatensätze nie echte Systeme erreichen.
Personenbezogene Daten fernhalten
Verwenden Sie erfundene Namen und Adressen, und nutzen Sie für E-Mails reservierte Beispielnamen wie person@example.com und person@example.invalid. IANA pflegt example.com und example.org für Dokumentationszwecke und sagt, sie dürften ohne vorherige Abstimmung als anschauliche Beispiele verwendet werden. RFC 2606 reserviert die Top-Level-Namen .test, .example, .invalid und .localhost und beschreibt .invalid als gedacht für Namen, die auf den ersten Blick offensichtlich ungültig sind, was zu einer Testadresse passt, die nie einer echten Person gehören soll.
Ein reservierter Name ist eine Kennzeichnung, keine Sperre, verlassen Sie sich also nicht allein auf die Domain, um zu verhindern, dass eine Nachricht Ihr System verlässt. Schalten Sie den ausgehenden Versand in der Testkopie des Workflows ab oder richten Sie ihn auf eine kontrollierte Senke, also ein Postfach oder Erfassungswerkzeug, das Sie betreiben und das Nachrichten sammelt, statt sie an externe Empfänger zuzustellen. IANA sagt außerdem, dass die Webdienste ihrer Beispieldomains nach bestem Bemühen betrieben und nicht für Produktionsanwendungen ausgelegt sind. Vermeiden Sie daher Konzepte, die voraussetzen, dass diese Domains antworten.
Wenn Sie unbedingt gegen eine Kopie echter Datensätze testen müssen, behandeln Sie die Kopie als sensibel und beschränken Sie, wer sie sehen kann. Lassen Sie Testnachrichten niemals an echte Kunden senden können.
Ein hypothetisches Beispiel
Stellen Sie sich einen Workflow vor, der Angebotsanfragen weiterleitet: Anfragen unter einem festgelegten Wert erhalten eine automatische Eingangsbestätigung, größere gehen an die verantwortliche Person. Die Testmenge enthält eine kleine Anfrage, eine genau am Schwellenwert, eine darüber, eine ohne E-Mail-Adresse, eine mit einer E-Mail-Adresse mit angehängtem Leerzeichen und dieselbe Anfrage, zweimal übermittelt. Die erwarteten Ergebnisse werden zuerst aufgeschrieben. Der Test zeigt, dass der Datensatz am Schwellenwert falsch geroutet wird, was sich jetzt günstiger finden lässt als nachdem eine echte Kundin oder ein echter Kunde gewartet hat. Dieses Beispiel ist hypothetisch.
Behalten Sie die Menge und verwenden Sie sie wieder
Bewahren Sie die Testdatensätze bei den Workflow-Notizen auf. Lassen Sie die Menge bei jeder Änderung des Workflows erneut laufen und ergänzen Sie einen neuen Datensatz, wenn ein echtes Problem auftaucht. Mit der Zeit wird die Menge zu einer Aufzeichnung von allem, was je schiefgegangen ist.