Os testes no pipeline de integração

Seu pipeline de integração leva vinte e seis minutos. Um desenvolvedor abre um pull request, dispara a execução e vai fazer outra coisa. Meia hora depois, um teste end-to-end está vermelho; ele roda de novo sem olhar, porque "esse aí falha de vez em quando". Cinquenta minutos depois do primeiro commit, o merge passa. Com cinco pull requests por dia, a equipe perdeu quatro horas de espera e, principalmente, o hábito de ler as falhas.

Esse é o ponto de virada a evitar, e ele não tem nada a ver com a qualidade de cada teste isoladamente. Uma suíte é útil enquanto o veredito chega rápido o bastante para continuar associado à mudança que o disparou, e enquanto um teste vermelho significar de fato "alguma coisa quebrou". Passados uns dez minutos, as pessoas mudam de contexto. Depois de algumas falhas aleatórias toleradas, param de ler. Esta lição trata, portanto, de duas grandezas: o tempo de execução e a taxa de falsas falhas. Todo o resto decorre disso.

Dividir a execução em etapas

Não dispare tudo ao mesmo tempo. Os testes rápidos devem dar seu veredito antes que os lentos comecem, para falhar cedo e liberar os runners.