A Ramp reduziu sua suíte de testes de 45 minutos para menos de 5 minutos apostando em ganhos assimétricos

Em julho de 2023, a suíte de testes do monólito Python da Ramp levava 45 minutos para rodar, e os testes lentos estavam represando a fila de merge em toda a empresa — os engenheiros bloqueavam meio dia só para acompanhar as mudanças pendentes. Dois anos antes, um post interno já havia sinalizado que testes lentos prejudicavam a produtividade da engenharia, mas nada tinha sido feito desde então.

Em vez de se comprometer com uma grande reescrita, a equipe primeiro mediu: cerca de 38 dos 45 minutos vinham da própria invocação do pytest. A análise de perfil mostrou que a execução dos testes era limitada pela CPU, então a primeira correção — CPUs mais rápidas — reduziu o tempo de execução em cerca de 50% por si só, o maior ganho isolado de todo o projeto e o que exigiu menos esforço para encontrar.

A partir daí, os engenheiros se dividiram e conduziram experimentos baratos e paralelos, limitados ao contexto que cada um já tinha: o cache de camadas do Docker em runners auto-hospedados economizou mais de um minuto; um algoritmo reescrito de divisão de trabalho do pytest-xdist economizou de 2 a 3 minutos; mais bancos de dados de teste e configurações ajustadas de conexão do Postgres resolveram a contenção de locks quando mais de 20 workers acessavam o mesmo banco. Nem todo experimento compensou — montar os dados de teste na RAM não mostrou ganho e foi descartado —, mas cada um era barato o suficiente para valer a tentativa.

Buscar experimentos baratos com alto potencial de ganho e parar no momento em que os ganhos diminuem

Medir primeiro (38 dos 45 minutos eram a própria chamada do pytest, limitada pela CPU) fez com que a equipe corrigisse o gargalo real em vez de adivinhar.

Fazer primeiro a correção de maior alavancagem e menor esforço (CPUs mais rápidas, ganho de ~50%) criou impulso e liberou tempo para explorar ideias mais arriscadas.

Dividir em experimentos paralelos de baixo custo permitiu à equipe testar muitas hipóteses rapidamente em vez de apostar tudo em uma única grande mudança.

Registrar em gráfico o tempo economizado por mudança tornou visível a curva de retornos decrescentes, dando à equipe um sinal concreto para parar em vez de continuar polindo em busca de ganhos marginais.

Meça antes de ajustar, corrija primeiro o item de maior alavancagem e depois conduza um portfólio de experimentos baratos em paralelo — e use o tamanho decrescente de cada ganho como sinal para parar.

Após uma semana, a suíte rodava em menos de 5 minutos, uma redução de aproximadamente 70% ou mais em relação aos 45 originais. As novas melhorias ao final da semana reduziam apenas segundos (menos de 5%) do tempo de execução, o que a equipe usou como sinal para parar e mover as ideias restantes para um backlog de longo prazo em vez de continuar ajustando.