Ir para o conteúdo principal

Jest 27: Novos Padrões para o Jest, edição 2021 ⏩

· 8 min de leitura"
Tim Seckinger
Tim Seckinger
Tradução Beta Não Oficial

Esta página foi traduzida por PageTurner AI (beta). Não é oficialmente endossada pelo projeto. Encontrou um erro? Reportar problema →

No post do Jest 26 há cerca de um ano, anunciamos que após dois lançamentos principais com poucas mudanças significativas, o Jest 27 ajustaria configurações para estabelecer padrões melhores em projetos novos ou que possam migrar suavemente. Isso nos permite remover alguns pacotes da distribuição padrão do Jest 28 e publicá-los como módulos instaláveis e plugáveis separadamente. Todos com os novos padrões se beneficiam de um tamanho de instalação menor, enquanto quem precisa desses pacotes ainda pode instalá-los separadamente.

Com a primeira grande mudança de padrões desde os Novos Padrões para o Jest introduzidos na seminal versão 15, o Jest 27 chega para manter o framework rápido, enxuto e relevante no futuro. Explicaremos essas mudanças de padrões e outras alterações significativas neste post, mas primeiro, vamos conhecer novos recursos empolgantes!

Atualizações de recursos

Primeiro, o modo interativo que você talvez conheça da revisão e atualização de snapshots falhos agora também pode ser usado para percorrer testes falhos um por um. Créditos ao colaborador de primeira viagem @NullDivision pela implementação deste recurso!

Execução interativa de testes falhos

Falando em snapshots, um dos recursos mais empolgantes que lançamos nos últimos anos são os Snapshots em Linha, que chegaram em um lançamento menor do Jest 23 há quase três anos. Porém, eles vinham com a restrição de que projetos que quisessem utilizá-los precisavam usar o Prettier para formatar seu código, pois era isso que o Jest usaria para garantir que o arquivo onde os snapshots são gravados permanecesse corretamente formatado.
Assim, durante a maior parte desses anos, tivemos um pull request em andamento para eliminar essa restrição e permitir Snapshots em Linha sem Prettier. Ele acumulou bem mais de cem comentários, sem considerar PRs derivados já implementados, e até mudou de responsável após a submissão inicial por outro colaborador de primeira viagem, @mmkal, sob o hilário título provisório 'Snapshots em Linha Mais Feios'. Com a ascensão meteórica do Prettier recentemente, essa melhoria talvez seja menos necessária hoje do que em 2018, mas ainda conhecemos a frustração de entrar em um projeto sem Prettier e de repente não poder mais usar snapshots em linha. Nunca mais!

O principal motivo da demora foi, surpreendentemente, um erro de falta de memória em nosso pipeline de build. Descobrimos que as dependências carregadas para cada arquivo de teste realizarem análise, inserção de snapshots e impressão geram sobrecarga significativa de tempo e memória.
Com alguns truques, aceleramos a inicialização por arquivo de teste em cerca de 70% comparado ao Jest 26. Note que você dificilmente verá essa magnitude de ganho no seu projeto—seriam necessários muitos arquivos de teste com execução muito rápida para notá-lo melhor, e a sobrecarga ao usar um ambiente JSDOM anula qualquer melhoria desse tipo.

Em outras notícias, o suporte nativo a ESM avança, mas complexidades importantes, como em mocks, ainda persistem, e continuamos enxergando a migração para ESM como um esforço gigante do ecossistema, onde Node e muitas ferramentas e pacotes cruciais precisam se apoiar mutuamente para oferecer uma experiência satisfatória.
O suporte a ESM para conectar módulos ao Jest está mais avançado—runners personalizados, reporters, plugins de monitoramento e outros módulos já podem ser carregados como ES modules.

Também integramos um PR para lidar com arquivos de teste vinculados simbolicamente ao diretório de testes, um recurso muito desejado por usuários do Bazel.

Outro PR permitiu que transforms fossem assíncronos, um requisito para suportar transpilação eficiente com ferramentas como esbuild, Snowpack e Vite.

Alterando os padrões

Até agora, ao usar o Jest na configuração padrão, você estava executando — talvez sem saber — um código bifurcado há muitos anos do executor de testes Jasmine 2.0, que fornece funções como describe, it e beforeEach. Em 2017, Aaron Abramov escreveu inicialmente um substituto para o código do Jasmine chamado jest-circus, projetado para melhorar mensagens de erro, manutenibilidade e extensibilidade.
Após anos de uso em larga escala no Facebook e no próprio Jest, além da recente adoção no create-react-app, estamos confiantes que o jest-circus é altamente compatível com jest-jasmine2 e deve funcionar na maioria dos ambientes com pouco ou nenhum esforço de migração. Pode haver diferenças menores na ordem de execução e rigor, mas não esperamos grandes dificuldades de atualização, exceto para códigos que dependam de APIs específicas do Jasmine como jasmine.getEnv(). Se você depende extensivamente dessas APIs, pode voltar ao executor baseado no Jasmine configurando "testRunner": "jest-jasmine2".

Executar testes em um ambiente JSDOM acarreta uma sobrecarga significativa de desempenho. Como esse era o comportamento padrão do Jest até agora, usuários que escrevem aplicativos Node, por exemplo, podem nem saber que recebem um custoso ambiente DOM que nem sequer precisam.
Por esse motivo, estamos alterando o ambiente de teste padrão de "jsdom" para "node". Se você for afetado por essa mudança por usar APIs DOM e não tiver o ambiente de teste explicitamente configurado, deve receber um erro ao acessar, por exemplo, document. Você pode configurar "testEnvironment": "jsdom" ou usar configuração de ambiente por arquivo para resolver isso.
Para projetos mistos onde alguns testes exigem ambiente DOM e outros não, recomendamos usar o ambiente rápido "node" por padrão e declarar exatamente os testes que precisam do DOM usando docblocks.
Na próxima versão principal, planejamos remover jest-jasmine2 e jest-environment-jsdom da árvore de dependências do Jest, exigindo que sejam instalados explicitamente. Assim, muitos usuários se beneficiarão de uma instalação menor sem componentes desnecessários.

Outro padrão que estamos alterando afeta os Fake Timers (Temporizadores Falsos), também conhecidos como Timer Mocks. Introduzimos uma implementação "moderna" opcional de Fake Timers no Jest 26, acessível transparentemente pela mesma API, mas com simulações mais abrangentes, como para Date e queueMicrotask.
Essa implementação moderna de temporizadores falsos será agora o padrão. Se você está entre os poucos afetados por diferenças sutis de implementação que dificultam a migração, pode recuperar a implementação antiga usando jest.useFakeTimers("legacy") ou, se estiver habilitando temporizadores falsos globalmente via configuração, "timers": "legacy".

Recursos com mudanças que quebram compatibilidade

Introduzimos mais algumas pequenas mudanças que quebram compatibilidade para ajudar você a evitar erros, proibindo ações que podem ocorrer facilmente sem intenção:

  • O mesmo callback de teste done não pode ser chamado mais de uma vez,

  • chamar done e retornar uma Promise não podem ser combinados,

  • um bloco describe não deve retornar nada,

e tornamos alguns tipos do TypeScript mais rigorosos.

Os módulos usados nas seguintes opções de configuração agora são transformados como o resto do seu código, o que pode ser uma mudança de comportamento se você dependia que eles fossem carregados como estão:

  • testEnvironment

  • runner

  • testRunner

  • snapshotResolver

Outras alterações de comportamento

Removemos algumas funções há muito tempo descontinuadas:

  • jest.addMatchers (use expect.extend em vez disso)

  • jest.resetModuleRegistry (use jest.resetModules em vez disso)

  • jest.runTimersToTime (use jest.advanceTimersByTime em vez disso)

Muitos pacotes do Jest foram migrados para usar exportações no estilo ESM (embora ainda sejam distribuídos como CommonJS), então se você consome, por exemplo, pretty-format diretamente, talvez precise ajustar sua importação para uma importação default.

Removemos o suporte para o Node 13 — mas o Jest sempre suporta as versões Atual e todas LTS do Node, e o Jest 27 continua suportando o Node 10, que apenas recentemente saiu de manutenção.

Como sempre, o changelog completo e a lista de alterações de comportamento podem ser vistos aqui.

Finalmente, gostaríamos de agradecer à comunidade por mais uma vez conceder ao Jest uma altíssima taxa de satisfação de 96% na pesquisa State of JS 2020! Fiquem seguros, e esperamos que continuem a aproveitar o Jest nos próximos anos e versões! 🃏