O Vitest 5 chegou à versão estável com uma promessa de desempenho que vem acompanhada de ferramentas para descobrir por que uma suíte está lenta ou instável. O upgrade, porém, começa por uma checagem objetiva: a nova versão exige Node.js 22.12 ou superior e Vite 6.4 ou superior.
Para quem acompanhou o release candidate, a notícia agora não é a existência dos recursos. É que eles entraram no canal estável e podem ser avaliados num branch de migração com a suíte real do projeto.
Os ganhos variam porque as suítes também variam
Nos benchmarks publicados pela equipe, os ganhos ficaram entre 8% e 53% em cenários com aplicações geradas para simular projetos. Os maiores avanços apareceram em pools de VM, Browser Mode e suítes grandes. Algumas configurações ficaram numa faixa de aproximadamente três pontos percentuais, para mais ou para menos.
É uma forma honesta de apresentar performance: não existe “53% mais rápido” para todo repositório. Transformação de módulos, ambiente, isolamento, quantidade de projetos e cobertura mudam o gargalo. A métrica que interessa é a sua, coletada antes e depois com cache e concorrência comparáveis.
vitest doctor procura configuração, não doença imaginária
O novo vitest doctor experimenta configurações e sugere ajustes para a suíte. Isso ajuda a tirar tuning do campo da superstição. Em vez de copiar a configuração de um monorepo enorme, o comando testa alternativas no projeto atual e aponta o que demonstrou diferença.
Os relatórios de duração também passam a mostrar percentuais, e o runner oferece hints de performance. A versão reduz viagens entre workers, estabiliza o cache de módulos do filesystem, melhora pools de VM e limita o custo de mesclar cobertura. Projetos inline podem compartilhar um servidor Vite, diminuindo trabalho duplicado.
Trace View dá contexto ao teste de navegador
No Browser Mode, o Trace View registra interações, assertions e snapshots do DOM. Quando um teste falha no CI, a diferença entre “botão não encontrado” e uma sequência visível de estados é enorme. O trace aproxima a investigação do que ferramentas de end-to-end já oferecem, sem abandonar a ergonomia do Vitest.
A opção --repeats ataca outro problema conhecido: flakiness que só aparece depois de várias execuções. Repetir um teste não corrige corrida ou vazamento de estado, mas aumenta a chance de reproduzir e medir antes de mexer no código.
Um roteiro de migração que cabe num pull request
- Confirme Node 22.12+ em desenvolvimento, CI e imagens de container.
- Atualize Vite para pelo menos 6.4 e leia o guia de breaking changes.
- Registre tempo, memória e resultado da cobertura antes da troca.
- Atualize Vitest sem misturar refatorações de teste no mesmo commit.
- Rode a suíte completa, Browser Mode e
vitest doctor. - Compare resultados e investigue regressões por pool ou projeto.
Monorepos merecem atenção especial ao compartilhamento do servidor Vite e às diferenças entre projetos. Testes com mocks sensíveis a isolamento também devem ser executados em ordem variada. Se cobertura é requisito de merge, compare não apenas o percentual final, mas arquivos e sourcemaps mapeados.
Atualizar por ferramenta ou por resultado?
Trace View e doctor são bons motivos para experimentar. A decisão de adotar vem do conjunto: compatibilidade do runtime, estabilidade da suíte e ganho medido. Se a infraestrutura ainda depende de Node antigo, forçar a migração apenas pelo número da versão transfere o custo para outro lugar.
Vitest 5 parece mais interessante quando tratado como uma oportunidade de observar a suíte. Uma atualização que só troca o pacote pode render segundos. Uma atualização que revela testes lentos, estados vazando e traces úteis melhora o ciclo inteiro.