Velocidade e confiabilidade da suíte

Uma suíte de dezoito minutos deixa de ser executada antes do push. Uma suíte que falha uma vez em cada seis por razões variáveis deixa de ser lida: a equipe reexecuta, e se passar, faz o merge. Nos dois casos, a suíte deixou de cumprir seu papel, e não é porque contém testes ruins — é porque se tornou cara demais ou ruidosa demais para merecer atenção.

Essas duas degradações se instalam aos poucos e são tratadas da mesma maneira: pela medição. Ninguém adivinha corretamente onde o tempo de uma suíte de testes é gasto, e ninguém adivinha a causa de um teste instável. Ambos se constatam, com ferramentas que já estão no seu projeto. Esta lição começa, portanto, lendo os dados que o Surefire e o Gradle já produzem, depois passa à paralelização, às causas reais da instabilidade e ao que a cobertura de código realmente mede.

Medir antes de otimizar

O Surefire escreve um arquivo XML por classe de teste em target/surefire-reports, com a duração de cada método. Uma ordenação por duração decrescente basta para identificar os culpados.

# Os 15 testes mais lentos, todas as classes combinadas
grep -h '<testcase' target/surefire-reports/*.xml \
  | sed -E 's/.*name="([^"]+)".*classname="([^"]+)".*time="([^"]+)".*/\3 \2#\1/' \
  | sort -rn | head -15