Eine Integration durchgängig testen
Eine Integration, die auf dem Happy Path funktioniert, ist eine halbe Integration. Das hier ist die andere Hälfte — die Tests, die entscheiden, ob eine schlechte Nacht zehn Minuten kostet oder eine Woche.
Mit Fixtures testen, nicht mit den Daten von heute
Ein Fixture ist ein Datensatz, den Sie bewusst anlegen, damit ein Test wiederholbar ist. Die Alternative — gegen das testen, was heute zufällig im System liegt — liefert Ergebnisse, die nächste Woche niemand reproduzieren kann.
Die Fixtures, die sich in der Sandbox lohnen:
| Fixture | Testet |
|---|---|
| Eine Bestellung je Status | Dass das ERP pending, placed, in_fulfillment, completed und cancelled korrekt liest |
Eine Bestellung mit customer_order_number | Dass die PO-Nummer des Käufers bis ins ERP überlebt |
| Eine Bestellung über zwei Kostenstellen | Dass Positionsdaten nicht verloren gehen |
| Eine Bestellung mit teilgelieferter Position | Die drei Status, die sich absichtlich widersprechen |
| Ein Artikel im 12er-Gebinde | Mengen- und Einheitenbehandlung |
| Ein Artikel mit Komma-Dezimalpreis | Locale-Behandlung in Dateien |
| Eine gesperrte Organisation | Dass der Checkout ablehnt |
| Eine Organisation mit Freigabeschwelle | Dass eine Bestellung legitim als pending ankommen kann |
Ein Artikel mit null verfügbar, aber positivem on_hand | Reservierungslogik, der klassische Phantom-Fehlbestand |
| Ein auslaufender Artikel auf einer gespeicherten Liste | Umwandlungsverhalten, wenn ein Artikel verschwindet |
Bauen Sie sie einmal, behalten Sie sie als Teil des Sandbox-Seeds, und legen Sie sie bei jedem Refresh neu an.
Die Tests, die die meisten Projekte auslassen
Vier, und jeder entspricht einem echten Produktionsvorfall.
1. Der Idempotenztest
Was Sie tun: dieselbe Bestellung zweimal ans ERP senden — dasselbe Event, dieselbe Bestellnummer. Danach dieselbe Importdatei zweimal laufen lassen.
Was passieren muss: eine Bestellung im ERP. Ein Datensatzbestand nach dem Import, nicht zwei, und kein Fehler.
Das zählt, weil es auf dieser Plattform keinen
Idempotency-Key-Header gibt. Idempotenz ist eine Eigenschaft Ihrer
Daten, nicht eines Request-Headers, und sie ruht auf zwei Dingen: dem
Abgleich über einen stabilen Geschäftsschlüssel (SKU, Kundennummer,
Bestellnummer — nie eine interne Id) und Upserts statt Inserts. Jeder Import
sollte heißen „mach den Datensatz so".
Der klassische Fehler, den das fängt, ist eine Bestandsdatei, die als Delta statt als Zustand angewendet wird. Läuft sie zweimal, steht der Bestand um genau die Bewegungen einer Nacht falsch — still, ohne Eintrag in irgendeinem Log.
2. Der Timeout-Test
Was Sie tun: die Verbindung bei einem Schreibzugriff mitten im Request kappen, oder die Integration auf einen Endpoint zeigen, der die Verbindung annimmt und nie antwortet.
Was passieren muss: die Integration wiederholt, und das Ergebnis ist weiterhin eine Bestellung, nicht zwei.
Ein 429 heißt: Es ist nichts passiert, Wiederholen ist immer sicher. Ein
Timeout sagt Ihnen nichts darüber, ob die andere Seite den Request
verarbeitet hat — und genau für diesen Fall existiert Idempotenz. Eine
Integration, die beides gleich behandelt, wird doppelte Lieferungen
erzeugen.
3. Der Replay-Test
Was Sie tun: in den Delivery attempts des Webhooks ein Event erneut zustellen, das der Empfänger bereits verarbeitet hat.
Was passieren muss: der Empfänger dedupliziert über die Event-Id und tut
nichts. Keine zweite Bestellung, kein Fehler, eine 2xx-Antwort.
Zustellung ist at-least-once. Dasselbe Event wird irgendwann zweimal
ankommen, meist in einer Nacht, in der jemand den Empfänger neu ausrollt.
Fahren Sie danach die Gegenprobe: eine Zustellung mit verfälschter Signatur
abspielen und prüfen, dass der Empfänger 401 antwortet und nicht
verarbeitet.
4. Der Empfänger-down-Test
Was Sie tun: den Empfänger länger stoppen, als das gesamte Wiederholungsfenster dauert, dann wieder hochfahren.
Was passieren muss: das Zustellprotokoll der Plattform zeigt die Fehlschläge, das Ziel wird womöglich automatisch deaktiviert, und — der Kern des Tests — Ihr Abgleichslauf findet die verpassten Bestellungen.
Ist die Antwort auf „was passiert mit den Bestellungen, die nie ankamen?" ein Schulterzucken, fehlt der Integration ihr Sicherheitsnetz. Ein Webhook ist der schnelle Pfad; ein geplanter Abgleich ist die Garantie. Siehe Häufige API-Aufgaben nach Job.
Volumen und Locale
Zwei weitere, die eine bestimmte Klasse von Go-live-Fehlern fangen:
Das echte Volumen einmal fahren. Nicht 3.000 Sandbox-Produkte — Ihre tatsächlichen 400.000. Das Rate-Limit gilt je Tenant und wird geteilt, und ein Job, der bei Sandbox-Größe unauffällig ist, kann bei Produktionsgröße Ihre gesamte Zuteilung verbrauchen. Siehe Rate-Limits, Kontingente und Fair Use.
Eine Datei mit Zahlen in deutscher Locale testen. 19,90, gelesen von
einem System, das 19.90 erwartet, erzeugt Preise, die um den Faktor
hundert falsch sind, ohne Fehler irgendwo. Testen Sie auch einen Umlaut in
einem Firmennamen und ein ;-getrenntes CSV.
Die Go-live-Checkliste
Messen Sie das Projekt daran. Jede Zeile hat eine Ja/Nein-Antwort und einen Namen dahinter.
Zugang
- Produktionsschlüssel angelegt, gescopet auf genau das, was die Integration nutzt — nicht
* - Secrets in einem Secret-Manager, nicht in E-Mail, Chat oder Ticket
- Schlüsselinventar aktualisiert: welcher Schlüssel, welche Integration, welcher Verantwortliche, wen man anruft
- Sandbox-Schlüssel widerrufen oder zum Widerruf terminiert
Daten
- Feld-Hoheit vereinbart und aufgeschrieben — siehe Das führende System festlegen
- Importprofile mappen nur die Felder, die die Quelle besitzt
- Jeder Abgleich läuft über einen Geschäftsschlüssel, nie über eine interne Id
- Codes zwischen Sandbox und Produktion identisch —
thread_size, nichtthread_size_1
Verhalten
- Idempotenztest bestanden, in beiden Richtungen
- Timeout-Test bestanden
- Replay-Test bestanden, einschließlich des Falls mit falscher Signatur
- Empfänger-down-Test bestanden, und der Abgleich hat die Lücke gefunden
- Retry-Policy dokumentiert: wie viele Versuche, wie lange, was danach passiert
Betrieb
- Alarme laufen auf eine Team-Adresse, nie auf eine Person
- Der Alarm „bis 03:00 Uhr kam keine Datei" existiert, nicht nur „der Lauf ist fehlgeschlagen"
- Für jede Integration ist ein Verantwortlicher benannt
- Das Runbook sagt, was zu tun ist, wenn es sonntags um 02:00 Uhr bricht
-
X-Request-IDwird bei jedem Aufruf protokolliert - Ein Rollback-Plan existiert: wie man die Integration stoppt, ohne den Shop zu stoppen
Die erste Woche
- Jemand liest die API- und Zustellprotokolle täglich, nicht wöchentlich
- Der Abgleich wird am ersten Tag von Hand gefahren und von Hand verglichen
- Den ersten nächtlichen Lauf mit vollem Volumen beobachtet eine Person
Was Sie danach prüfen
In den ersten zwei Wochen, täglich:
- Fehlerrate nach Statuscode — siehe Integrationen überwachen.
- Die Warteschlange fehlgeschlagener Webhooks ist leer.
- Der Abgleich findet null fehlende Bestellungen.
- Keine Integration wiederholt ständig mit Erfolg — das wäre ein Limit, an dem Sie leise entlangleben.
Weiter
- Integrationen überwachen — die tägliche Lektüre von hier an.
- Mit API-Änderungen umgehen — wie es nach dem Go-live weiterläuft.