Os testes são um pilar do desenvolvimento moderno de software, garantindo a confiabilidade e a funcionalidade do código. O Jest é amplamente reconhecido por sua simplicidade e facilidade de uso. No entanto, como qualquer ferramenta, seu desempenho pode variar conforme a configuração e o ambiente em que é executado. Neste post, vamos analisar algumas descobertas práticas obtidas ao executar o Jest em um ambiente de uma grande aplicação e discutir estratégias para otimizar o tempo dos testes.
Ambiente e configuração de testes
Nosso ambiente de testes é uma aplicação JavaScript bem grande em execução em um MacBook M3. O motivo deste benchmark é que os MacBooks M3 são rápidos demais; assim, testes instáveis passam normalmente e é difícil entender o porquê. A ideia é encontrar uma forma de fazer os testes instáveis aparecerem localmente. Testes instáveis são aqueles que podem passar ou falhar em diferentes execuções sem que haja alterações no código. Eles normalmente significam que o teste tem aspectos que dependem de quanto tempo leva a execução.
Para entender como o Jest se comporta sob diferentes cargas e configurações, realizei uma série de testes:
- Modo de baixo consumo com build paralelo: executar a suíte de testes com o modo de baixo consumo ativado no MacBook, enquanto uma aplicação ainda maior era compilada em paralelo, levou cerca de 195 segundos para terminar.
- Condições ociosas com diferentes quantidades de workers: em seguida, executamos os testes em condições ociosas (sem outros processos significativos em execução), variando a quantidade de workers. Veja o que encontramos:
- 4 workers: 164 segundos
- 6 workers: 143 segundos
- 7 workers: 142 segundos
- 8 workers: 137 segundos, mas com aumento de testes instáveis
- 12 workers: 136 segundos, também com mais testes instáveis
- Executar “in band” (sem processamento paralelo): os testes ficaram significativamente mais lentos, a ponto de precisarmos interrompê-los.
Descobertas principais
Impacto da quantidade de workers
Os dados revelam uma tendência clara: aumentar a quantidade de workers até certo ponto pode reduzir o tempo de execução dos testes. No entanto, após determinado limite (neste caso, 8 workers), os benefícios se estabilizam e o risco de testes instáveis aumenta.
Opções de configuração do Jest
Também exploramos o impacto de opções específicas da configuração do Jest:
bail: x: (no jest.config.js) essa opção permite que o Jest pare de executar os testes após o primeiro número x de falhas. É útil para identificar falhas rapidamente sem executar a suíte inteira, especialmente em ambientes de integração contínua (CI).--no-cache: desativar o cache do Jest fez os testes ficarem mais lentos. O cache é um recurso poderoso que evita retraduzir arquivos que não mudaram, acelerando execuções posteriores.--maxWorkers=x: essa opção controla o número de threads de worker usadas pelo Jest. Nossos testes mostraram que ajustar esse número é um equilíbrio delicado entre velocidade e confiabilidade.
Recomendações para desempenho ideal
Com base em nossas descobertas, seguem algumas recomendações para otimizar o tempo dos testes com Jest:
- Ajuste a quantidade de workers ao seu ambiente: comece com uma quantidade moderada de workers e aumente-a gradualmente para encontrar o ponto ideal para seu projeto e hardware específicos.
- Use o cache com sabedoria: a menos que exista um motivo específico para desativá-lo, mantê-lo ativo pode reduzir significativamente o tempo dos testes.
- Considere o bail para feedback mais rápido no CI: ao executar testes em um ambiente de CI, usar a opção bail pode ajudar a identificar falhas mais rapidamente, sem esperar a suíte inteira terminar.
- Monitore a instabilidade: ao ajustar workers e outras configurações, fique atento aos testes instáveis, que podem enfraquecer a confiança na sua suíte de testes.
Conclusão
O Jest oferece flexibilidade e opções para otimizar os testes de acordo com as necessidades do seu projeto e os recursos do seu hardware. Nossa exploração reforça a importância de ajustar cuidadosamente as configurações do Jest e oferece um ponto de partida para desenvolvedores que querem melhorar a eficiência dos testes. Lembre-se: a configuração ideal pode variar bastante, então experimentar de acordo com seu contexto específico é essencial.
