Vitest 5: aproveite a migração para remover dependências escondidas entre testes

O Vitest 5.0 combina otimizações de execução com padrões mais rigorosos para testes.[8] A equipe reporta ganhos de aproximadamente 8% a 25% na maior parte da bateria publicada e até 53% em cenários com pools de máquinas virtuais.[8] São números daquele benchmark, não uma promessa para qualquer repositório.

O ângulo mais interessante da atualização não é apenas diminuir minutos no CI. É descobrir quais testes passavam pelas razões erradas.

O que muda para quem desenvolve

O clearMocks passa a ser verdadeiro por padrão, asserções assíncronas sem espera passam a falhar e chamadas hoisted de vi.mock fora do nível superior produzem erro.[8] Minha recomendação é ler essas quebras como pistas sobre o contrato dos testes antes de procurar uma configuração que restaure o comportamento antigo.

Uma contagem de chamadas deveria ser explicável pelo cenário atual. Na revisão da migração, eu pediria que cada teste declarasse sua preparação e o que pretende observar, sem depender de uma história implícita da suíte.

As otimizações descritas incluem compartilhamento de servidor Vite entre projetos inline, cache de módulos em disco e menos comunicação entre processo principal e workers.[8] O novo vitest doctor executa configurações alternativas para sugerir opções mais rápidas.[8] Isso oferece um caminho de investigação mais concreto que copiar flags de outro projeto.

Como aplicar

Crie uma branch de migração e registre uma linha de base: versão do runtime, máquina, comando, duração, memória e quantidade de testes executados. Separe medições com cache frio e quente. Use várias execuções e mantenha a carga comparável.

Depois da atualização, classifique as falhas em três grupos: incompatibilidade de integração, mudança de semântica e defeito da própria suíte. Para assincronia, revise se a conclusão da operação está realmente vinculada ao término do teste. Para mocks, confira a preparação local e a contagem esperada por cenário.

Revise ainda a publicação dos artefatos do CI. Reporters, anexos e relatórios blob foram reunidos em .vitest/, então os caminhos de coleta precisam acompanhar a mudança.[8] Como critério de aceite, proponho exigir tanto o resultado dos testes quanto a presença dos relatórios esperados.

Cuidados e limites

Os requisitos mínimos divulgados são Vite 6.4 e Node.js 22.12; com Yarn, vite precisa ser instalado explicitamente como peer dependency.[8] A reportagem cita o pool de Workers da Cloudflare como integração cujo intervalo de compatibilidade preso ao Vitest 4 bloqueia a atualização.[8]

Confira o ecossistema antes de migrar o runtime de testes isoladamente. E não transforme um benchmark favorável em justificativa para reescrever uma suíte Jest funcional. Minha recomendação é medir ganho e custo de manutenção no projeto real. Velocidade só vale a pena se o teste continuar verificando o comportamento certo.

Fonte

[8] Fonte: InfoQ