Ein schlechtes Netzwerk in der CI simulieren

Das Fenster ist optional. Dieselbe ausführbare Datei läuft als Befehlszeilenprogramm, endet nach einer festgelegten Zeit von selbst und meldet, was passiert ist, so, dass eine Pipeline es lesen kann.

Die Form eines Schritts

Störe für die Dauer des Tests und lass es dann von selbst enden. Es gibt keinen Aufräumschritt, den man vergessen könnte:

BeanNetworkTester.exe --loss 10 --latency 200 --target myapp.exe --duration 60

In einem GitHub-Actions-Job auf einem selbst gehosteten Windows-Runner:

- name: Test the app on a poor connection
  shell: pwsh
  run: |
    Start-Process -FilePath BeanNetworkTester.exe `
      -ArgumentList '--loss 10 --latency 200 --target myapp.exe --duration 90'
    npm test

Zwei Dinge zum Runner: Das Abfangen von Datenverkehr braucht Administratorrechte, und ein gehosteter Runner gibt dir diese nicht, deshalb gehört das auf einen selbst gehosteten Windows-Rechner.

Jedes Ende hat einen Exit-Code

Nichts endet mit einem Traceback. Jede Art, wie ein Durchlauf enden kann, hat eine Nummer, sodass eine Pipeline „deine App ist fehlgeschlagen“ von „das Tool konnte nicht starten“ unterscheiden kann:

Code	Bedeutung
0	Wie gewünscht abgeschlossen.
1	Während der Ausführung ist etwas fehlgeschlagen.
2	Die Befehlszeile war fehlerhaft.
3	Eine Einstellung oder ein Wert war ungültig.
4	Eine Szenario-Datei wurde abgelehnt.
5	Eine Datei konnte nicht gelesen oder geschrieben werden.
6	Eine Annahme über den Ablauf hat sich nicht bestätigt.
7	Keine Administratorrechte, daher kann der Treiber nicht geladen werden.
130	Abgebrochen, meist mit Strg+C.
143	Von außen beendet.

Maschinenlesbare Ausgabe

--format json schreibt ein JSON-Objekt pro Zeile, Messwerte während des Durchlaufs und am Ende eine Zusammenfassung, sodass ein späterer Schritt darauf prüfen kann:

BeanNetworkTester.exe --loss 5 --duration 30 --format json > run.ndjson

Logzeilen gehen an die Standardfehlerausgabe und Daten an die Standardausgabe, sodass die Umleitung der Daten beides nie vermischt. --seed macht den Durchlauf wiederholbar, und das braucht ein instabiler Test, bevor irgendjemand darüber streiten kann.

Ein Probelauf, der nichts anfasst

Zwei Schalter machen es sicher, das einzubauen, bevor du ihm vertraust: --dry-run meldet, was die Einstellungen bewirken würden, und beendet sich, und --simulate lässt die ganze Engine gegen synthetischen Datenverkehr laufen, ohne den Treiber zu laden und ohne das Netzwerk anzufassen. Beides ist nützlich in einem Build, der den Rechner, auf dem er läuft, nicht stören darf.

Weiter

Bereit, dein eigenes Netzwerk absichtlich kaputtzumachen?

Für Windows herunterladen