Simule uma rede ruim no CI
A janela é opcional. O mesmo executável roda como ferramenta de linha de comando, termina sozinho depois de um tempo definido e informa o que aconteceu de uma forma que um pipeline consegue ler.
O formato de uma etapa
Degrade durante o tempo do teste e deixe parar sozinho. Sem etapa de limpeza para esquecer:
BeanNetworkTester.exe --loss 10 --latency 200 --target myapp.exe --duration 60Em um job do GitHub Actions, em um runner Windows auto-hospedado:
- 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 testDuas coisas sobre o runner: capturar tráfego exige permissões de administrador, e um runner hospedado não vai dá-las a você, então isto pertence a uma máquina Windows auto-hospedada.
Todo final tem um código de saída
Nada termina com um traceback. Cada jeito de uma execução terminar tem um número, então um pipeline consegue distinguir “seu aplicativo falhou” de “a ferramenta não conseguiu iniciar”:
| Código | O que significa |
|---|---|
| 0 | Concluído como pedido. |
| 1 | Algo falhou durante a execução. |
| 2 | A linha de comando estava incorreta. |
| 3 | Uma configuração ou um valor era inválido. |
| 4 | Um arquivo de cenário foi rejeitado. |
| 5 | Não foi possível ler ou gravar um arquivo. |
| 6 | Uma verificação sobre a execução não se confirmou. |
| 7 | Sem permissões de administrador, então o driver não pode ser carregado. |
| 130 | Interrompido, geralmente com Ctrl+C. |
| 143 | Encerrado de fora. |
Saída legível por máquina
--format json escreve um objeto JSON por linha, amostras durante a execução e um resumo no fim, para que uma etapa seguinte possa fazer asserções sobre ele:
BeanNetworkTester.exe --loss 5 --duration 30 --format json > run.ndjsonAs linhas de log vão para o erro padrão e os dados para a saída padrão, então redirecionar os dados nunca mistura os dois. --seed torna a execução repetível, que é o que um teste instável precisa antes de alguém poder discutir.
Uma execução de ensaio que não toca em nada
Duas opções deixam seguro ligar isso antes de confiar nele: --dry-run informa o que as configurações fariam e sai, e --simulate roda o mecanismo inteiro contra tráfego sintético, sem carregar o driver e sem tocar na rede. As duas são úteis em um build que não pode degradar a máquina em que roda.