Simular una mala red en CI
La ventana es opcional. El mismo ejecutable funciona como herramienta de línea de comandos, termina por sí solo pasado un tiempo fijado e informa de lo ocurrido de una forma que un pipeline puede leer.
La forma de un paso
Deteriora durante lo que dure la prueba y deja que se detenga solo. No hay ningún paso de limpieza que olvidar:
BeanNetworkTester.exe --loss 10 --latency 200 --target myapp.exe --duration 60En un job de GitHub Actions, en un runner de Windows autoalojado:
- 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 testDos cosas sobre el runner: capturar tráfico necesita permisos de administrador, y un runner alojado no te los dará, así que esto pertenece a una máquina Windows autoalojada.
Cada final tiene un código de salida
Nada termina con un traceback. Cada forma en que puede acabar una ejecución tiene un número, así que un pipeline puede distinguir «tu aplicación falló» de «la herramienta no pudo arrancar»:
| Código | Qué significa |
|---|---|
| 0 | Terminó como se pidió. |
| 1 | Algo falló durante la ejecución. |
| 2 | La línea de comandos era incorrecta. |
| 3 | Un ajuste o un valor no era válido. |
| 4 | Se rechazó un archivo de escenario. |
| 5 | No se pudo leer o escribir un archivo. |
| 6 | Una aserción sobre la ejecución no se cumplió. |
| 7 | Sin permisos de administrador, así que el controlador no puede cargarse. |
| 130 | Interrumpido, normalmente con Ctrl+C. |
| 143 | Terminado desde fuera. |
Salida legible por máquinas
--format json escribe un objeto JSON por línea: muestras mientras corre la ejecución y un resumen al final, para que un paso posterior pueda hacer aserciones sobre él:
BeanNetworkTester.exe --loss 5 --duration 30 --format json > run.ndjsonLas líneas de registro van a la salida de error estándar y los datos a la salida estándar, así que redirigir los datos nunca mezcla ambas. --seed hace la ejecución repetible, que es lo que necesita una prueba inestable antes de que nadie pueda discutir.
Una ejecución de prueba que no toca nada
Dos opciones hacen seguro conectarlo antes de confiar en él: --dry-run informa de lo que harían los ajustes y termina, y --simulate ejecuta todo el motor contra tráfico sintético, sin cargar el controlador y sin tocar la red. Ambas son útiles en una compilación que no debe deteriorar la máquina en la que se ejecuta.