Simulare una brutta rete in CI
La finestra è facoltativa. Lo stesso eseguibile funziona come strumento da riga di comando, termina da solo dopo un tempo stabilito e riporta cos’è successo in un modo che una pipeline sa leggere.
La forma di un passaggio
Degrada per la durata del test, poi lascia che si fermi da solo. Nessun passaggio di pulizia da dimenticare:
BeanNetworkTester.exe --loss 10 --latency 200 --target myapp.exe --duration 60In un job di GitHub Actions, su un runner Windows self-hosted:
- 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 testDue cose sul runner: catturare il traffico richiede privilegi di amministratore, e un runner ospitato non te li darà, quindi questo va su una macchina Windows self-hosted.
Ogni fine ha un codice di uscita
Niente finisce con un traceback. Ogni modo in cui un’esecuzione può terminare ha un numero, quindi una pipeline può distinguere «la tua app è fallita» da «lo strumento non è riuscito ad avviarsi»:
| Codice | Cosa significa |
|---|---|
| 0 | Terminato come richiesto. |
| 1 | Qualcosa è andato storto durante l’esecuzione. |
| 2 | La riga di comando era errata. |
| 3 | Un’impostazione o un valore non era valido. |
| 4 | Un file di scenario è stato rifiutato. |
| 5 | Non è stato possibile leggere o scrivere un file. |
| 6 | Una verifica sull’esecuzione non è stata soddisfatta. |
| 7 | Nessun privilegio di amministratore, quindi il driver non può essere caricato. |
| 130 | Interrotto, di solito con Ctrl+C. |
| 143 | Terminato dall’esterno. |
Output leggibile da macchina
--format json scrive un oggetto JSON per riga: campioni durante l’esecuzione e un riepilogo alla fine, così un passaggio successivo può fare asserzioni su di esso:
BeanNetworkTester.exe --loss 5 --duration 30 --format json > run.ndjsonLe righe di log vanno sullo standard error e i dati sullo standard output, quindi reindirizzare i dati non mescola mai i due. --seed rende l’esecuzione ripetibile, ed è ciò di cui un test instabile ha bisogno prima che qualcuno possa discuterne.
Una prova a secco che non tocca nulla
Due opzioni rendono sicuro collegarlo prima di fidarsi: --dry-run riporta cosa farebbero le impostazioni ed esce, e --simulate esegue l’intero motore su traffico sintetico, senza caricare il driver e senza toccare la rete. Entrambe sono utili in una build che non deve degradare la macchina su cui gira.