Jest 15.0: Novos Padrões para o Jest

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 →

Passamos o último ano tornando o Jest mais rápido, mais fácil de configurar, adicionando toneladas de recursos e criando testes de snapshot. No entanto, havia duas áreas onde investimos pouco: a saída do CLI e a experiência do usuário. Com o Jest 15, estamos mudando radicalmente o framework para torná-lo mais fácil de usar tanto para iniciantes quanto para usuários experientes. Estamos animados porque nosso investimento no Jest está dando frutos: podemos avançar rapidamente e melhorar o framework para o Facebook e a comunidade open source em velocidade máxima. O objetivo do Jest é vir com "baterias incluídas" e exigir o mínimo de configuração possível. Recentemente tivemos a chance de explicar nossa filosofia em uma issue do create-react-app.

A mudança mais importante são os novos padrões. Se você já usa o Jest, provavelmente precisará atualizar sua configuração para a versão 15. Na maioria dos casos, isso simplificará seu setup e o Jest fornecerá mensagens de erro úteis durante a atualização. Todos os novos padrões podem ser desativados conforme suas necessidades, mas ainda consideramos esses recursos essenciais em certas situações e continuaremos usando e dando suporte a eles no Facebook a longo prazo. Nossa documentação da API também foi completamente reescrita para refletir essas mudanças. Este pull request para React mostra algumas alterações necessárias em projetos existentes.

Novas mensagens de erro e resumos no CLI

Como parte do esforço para remover gradualmente o Jasmine do Jest, quase finalizamos a substituição de todos os matchers do Jasmine. Gastamos muito tempo ajustando cada mensagem de erro para cada matcher, dando o melhor sinal aos usuários quando um teste falha - o momento em que o Jest deve oferecer mais valor. Além de exibir os valores esperados e recebidos, agora é exibido um diff para os matchers toBe e toEqual para ajudar a identificar erros. Mais cores foram adicionadas e arquivos relevantes dos stack traces são destacados com mais ênfase.

Aqui está uma comparação do antes e depois em um terminal claro: Também funciona bem com cores escuras:

Novo comando watch

Reescrevemos completamente o jest --watch para torná-lo mais interativo. Agora é possível alternar entre executar todos os testes ou apenas arquivos de teste relacionados a arquivos alterados pressionando a ou o. Ao pressionar p, aparece um prompt que permite especificar um padrão de teste para focar em um conjunto específico de arquivos. Testes de snapshot podem ser atualizados pressionando u.

Melhorias no jest-react-native

Foram adicionados mocks para ListView, TextInput, ActivityIndicator, ScrollView e outros. Os mocks existentes foram atualizados para usar implementações reais, então snapshots existentes provavelmente precisarão ser atualizados ao migrar para o Jest 15. Uma função mockComponent foi adicionada ao jest-react-native para simular componentes nativos:

jest.mock('MyNativeComponent', () => {
  const jestReactNative = require('jest-react-native');
  return jestReactNative.mockComponent('MyNativeComponent');
});

Também houve várias melhorias em torno de simulação de imagens, módulo fetch e outras APIs nativas.

Mensagens de Console em Buffer

O Jest paraleliza a execução de testes entre workers para maximizar o desempenho. Anteriormente, o Jest encaminhava mensagens de console dos workers para o processo principal e as exibia imediatamente. Ao executar vários testes em paralelo, muitas vezes era difícil identificar qual teste e qual módulo estava chamando uma função de log. No Jest 15, todas as mensagens de console são armazenadas em buffer e exibidas junto com os resultados individuais dos testes. Além disso, o arquivo e número da linha da chamada de log são exibidos para facilitar a inspeção do código.

Compare a saída da versão anterior do Jest com o Jest 15:

Automocking Desativado

O automocking está agora desativado por padrão no Jest. Essa era de longe a funcionalidade mais confusa para novos usuários e, em muitos aspectos, não faz sentido para projetos pequenos. Introduzimos o automocking no Facebook e ele funcionou muito bem quando a unit testing foi adotada em uma base de código grande e já existente com poucos testes. Porém, com o tempo, percebemos que as pessoas gastavam mais tempo lutando com módulos mockados/não mockados do que levariam para escrever um teste normalmente. Também notamos que autores de bibliotecas frequentemente precisam de muitos módulos básicos que sempre tinham que ser desmockados manualmente. Mesmo no próprio Jest, percebemos que a maioria dos testes tinha o automocking desativado manualmente. Ainda acreditamos que o automocking explícito pode ser incrivelmente valioso. Essa mudança simplesmente troca mocks implícitos por mocks explícitos através de chamadas a jest.mock(moduleName).

Se você ainda quiser usar automocking por padrão, ative a configuração automock ou chame manualmente jest.enableAutomock() no seu arquivo de teste ou setup.

Padrões de Arquivos de Teste

Nem todo mundo usa a mesma convenção de pasta __tests__ para armazenar testes. O Jest 15 agora também procura arquivos terminados em .spec.js ou .test.js, dois padrões populares na comunidade. Além disso, o Jest 15 remove as opções de configuração testDirectoryName e testFileExtensions e pede que usuários migrem para a opção testRegex quando as configurações antigas forem usadas.

Persistência do Registro de Módulos

O Jest costumava resetar implicitamente todos os módulos antes de cada teste e recomendávamos importar módulos em beforeEach ou dentro dos testes. Isso é útil quando módulos têm estado local que não deve ser compartilhado entre testes. Porém, duas grandes mudanças aconteceram: módulos ES com sintaxe import de alto nível e um renovado interesse em escrever módulos funcionais sem estado.

Isso gerou inúmeras incompatibilidades. Também notamos que no Facebook nem mesmo usávamos esse reset implícito. Em vez disso, dependíamos de chamadas explícitas a jest.resetModules(), o que coloca engenheiros no controle sobre quando limpar todo o estado.

Veja um exemplo:

const React1 = require('react');
jest.resetModules();
const React2 = require('react');

React1 !== React2; // These two are separate copies of React.

A chamada para resetModules limpa o cache de require. Uma segunda chamada para requerer o mesmo módulo resultará em uma nova instanciação do mesmo módulo e todas as suas dependências. Esse recurso é especialmente útil ao lidar com módulos que têm efeitos colaterais, como jest-haste-map.

Acreditamos que é melhor dar controle aos usuários, então desativamos o reset implícito. Módulos podem ser resetados usando jest.resetModules() no código, e a opção resetModules pode ser ativada na configuração para restaurar o comportamento anterior.

Temporizadores Reais vs. Falsos

Por padrão, o Jest costumava mockar todas as funções de temporização como setTimeout ou process.nextTick e fornecia uma API jest.runAllTimers() para avançar temporizadores programaticamente. Isso é útil quando um código define um timeout longo que não queremos esperar em um teste.

Porém, percebemos que na maioria dos casos os usos são bastante isolados. A programação assíncrona também se tornou muito mais simples em nosso test runner. O Jest agora usa temporizadores reais por padrão.

Você ainda pode substituir isso especificando "timers": "fake" na configuração ou usando as opções globais jest.useRealTimers() e jest.useFakeTimers().

setupEnvScriptFile vs setupFiles

A opção de configuração setupEnvScriptFile estava depreciada há algum tempo. O Jest 15 a remove completamente e a substitui por setupFiles. Essa opção espera um array de caminhos de arquivos que são carregados em ordem antes da execução de um arquivo de teste.

Suporte Reescrito para Cobertura de Código

A cobertura de código no Jest pode ser utilizada através do comando jest --coverage e não requer pacotes adicionais ou configuração. O suporte à cobertura de código foi completamente reescrito, e uma nova opção collectCoverageFrom foi adicionada para coletar informações de cobertura de projetos inteiros, incluindo arquivos não testados. Note que esta opção utiliza globs, pois pretendemos simplificar ainda mais as opções de configuração no futuro e oferecer uma alternativa mais simples às expressões regulares. Veja o package.json do Jest para um exemplo.

Outras Melhorias

Uma enorme quantidade de outras melhorias também foi implementada:

• Melhoria de performance para execuções de testes menores.

• O Jest agora utiliza modo verboso quando apenas um único arquivo de teste é executado.

• Adicionada a opção --env para substituir o ambiente de teste configurado.

• O moduleNameMapper agora utiliza um algoritmo de resolução.

• O Jest agora funciona com caminhos que possuem caracteres especiais, como parênteses.

• Adicionado global.global ao ambiente Node.

• Corrigido o erro inválido do babel-plugin-jest-hoist quando uma função de usuário aleatória era chamada de mock.

• Corrigida a resolução de testEnvironment para priorizar jest-environment-{name} em vez de apenas {name}. Isso evita colisões de módulos ao usar jsdom como ambiente de teste.

• Melhorias na infraestrutura de testes do próprio Jest através da união de testes de integração e unitários. A cobertura de código agora é coletada para o Jest.

Ficamos felizes ao revisar todas as mudanças que fizemos com a ajuda da comunidade e não poderíamos estar mais animados para tornar o Jest ainda melhor nos próximos meses. Por favor, abra uma issue se algo não estiver funcionando conforme o esperado e envie-nos pull requests.

Próximo passo: Concurrent Reporter.