Jest: O Jest é 3x mais lento em todas as máquinas Windows (Windows 10 e inferior)

Relacionado: # 6783

O arranque é lento ou também está no modo de relógio? Se apenas durante a inicialização, você pode tentar instalar watchman , isso deve ajudar (https://facebook.github.io/watchman/docs/install.html)

Quando está passando pelos testes, parece bom a partir daí (EDITAR: Na verdade, é mais lento ao executar os testes também. Ele passa um por um na velocidade de 0,5 segundos enquanto a norma parece 0,05
segundos por teste)
No entanto, é lento para inicializar e / ou iniciar testes de brincadeira (atraso de cerca de 4-6 segundos, 4-6x mais lento do que máquinas mac)

Vou tentar vigia e voltar para você

Se você pudesse criar um perfil usando, por exemplo, ndb a inicialização e descobrir o que está lento, isso também seria de grande ajuda 🙂

O atraso ainda é lento mesmo com o watchman instalado.
Eu executei um teste de perfil com ndb executando "jest --verbose", aqui estão os resultados:

Captura de tela dos primeiros 1,7 segundos:

Captura de tela de 1,8 segundos a 2,7 segundos

Um arquivo .json e um arquivo .heapsnapshot salvos na guia do perfil no ndb após a gravação:

profiling.zip

@pfftdammitchris qual é o seu caso de uso [exato] em que você notou a lentidão?
(um arquivo ou vários arquivos)? (modo assistir ou não)? você pode fornecer o exemplo.
para um problema de modo de observação de arquivo => leia meu último comentário em: # 6783

É lento para arquivos únicos e múltiplos, com ou sem modo de observação. Praticamente toda vez que ele executa qualquer teste, há um atraso de 3+ segundos na inicialização dos testes, e é lento executar os testes um por um por 0,3 ou 0,4 ou 0,5 segundos cada, enquanto outros executores de teste como mocha / chai normalmente apenas executariam cada um como se parecesse 0,05 segundos cada.

Eu uso o jest no codesandbox e eles parecem executar o jest instantaneamente na inicialização / execução de testes, observei meus colegas de trabalho executarem o jest em suas máquinas mac e eles executam instantaneamente como normalmente. Até onde eu sei, são apenas máquinas Windows. Eu uso uma máquina windows no trabalho e a piada está tendo problema de lentidão aí, e também uso uma máquina windows em casa e o problema continua aqui.

Eu usei --runInBand, mas parecia ter desacelerado um pouco os testes de unidade ainda mais em 0,2 segundos adicionais cada, com base no sentimento.

Esclarecimento

Eu usei --runInBand, mas parecia ter desacelerado um pouco os testes de unidade ainda mais em 0,2 segundos adicionais cada, com base no sentimento.

=> você tentou com v24? de v23 a v24, você verá uma boa melhoria SOMENTE neste cenário:
_no rerun com watch e apenas se você executar em um arquivo (não na primeira execução) _
-> 2/3 seg. Para 0,4 / 0,5 seg.
mas comparado ao mac eu nunca tentei ... então talvez ainda seja ruim ... mesmo com a melhoria atual

@SimenB

1. Eu considero https://github.com/facebook/jest/issues/7110 como regressões de velocidade Jest [v22 vs v23] no Windows para TODOS os cenários problemáticos.
   onde # 6783 é um deles

2. Posso considerar esse problema como: problema de velocidade para jest [Mac vs Windows] para TODOS os cenários problemáticos.

Olá a todos !
Eu acumulo a lentidão do jest 24 e do windows 10 (800s para 400 testes!). A maneira mais rápida que encontrei de acelerar tudo isso é usar wsl em vez de powershell ou cmd. Agora, meus testes levam "apenas" 189 segundos.

Temos um conjunto de 144 arquivos de teste com 1302 testes que levam 1 minuto e 43 segundos para serem executados em uma máquina Windows 10 build 15063, Core i7 com 16 GB, e levam 28 segundos em um MAC OS Mojave com 32 GB. Nossa equipe de desenvolvimento é dividida igualmente entre Windows e Mac e os números são muito repetíveis.

Aqui está um teste simples -

it("works", () => {
  expect(1).toEqual(1);
});

Eu coloquei em codesandbox e ele funciona quase instantaneamente - https://codesandbox.io/s/4q8l0q52lw

na minha máquina Windows, embora demore 4-5 segundos -

PASSAR src / index.test.js
v funciona (62ms)

Suítes de teste: 1 aprovado, 1 total
Testes: 1 aprovado, 1 total
Instantâneos: 0 no total
Tempo: 4.158s
Executei todas as suítes de teste.

O teste em si levou 62 ms, mas o restante do equipamento de teste levou 4 segundos. Executar novamente o teste pressionando Enter leva o mesmo tempo.

Minhas configurações -

> npx envinfo --preset jest

  System:
    OS: Windows 10
    CPU: (4) x64 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
  Binaries:
    Node: 8.12.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.10.1 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.4.1 - C:\Program Files\nodejs\npm.CMD

Eu tentei com o WSL Ubuntu e obtive os mesmos resultados (4-5 segundos) - essas configurações -

  System:
    OS: Linux 4.4 Ubuntu 18.04.2 LTS (Bionic Beaver)
    CPU: (4) x64 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
  Binaries:
    Node: 8.10.0 - /usr/bin/node
    npm: 3.5.2 - /usr/bin/npm

Estou apenas começando com o Jest, então tenho testes bem simples e podem levar de 15 a 20 segundos para serem executados. Eu adoraria tê-los funcionando rapidamente - caso contrário, tendo a perder minha linha de pensamento!

@bburns leia o problema acima

@kensherman
você pode tentar com micromatch 4 em suas resoluções de fio. para ver se fica melhor no windows por favor?
https://github.com/facebook/jest/issues/7963#issuecomment -483985345

Estou em um novo MacBook Pro. Como tenho alunos no MacOS e no Windows 10, decidi adicionar mais duas partições à minha unidade; um para Windows 10 e outro para armazenamento compartilhado usando Tuxera NTFS.

Corri para este problema de velocidade hoje preparando uma lição de JavaScript que incorpora testes de unidade. Na verdade, estou executando o Jest no MacOS, mas o código e os testes estão localizados na partição NTFS compartilhada. Mesmo com todas as suítes marcadas como describe.skip , Jest leva mais de 10 segundos para ser concluído, tanto no modo de execução única quanto no modo de observação.

8 suítes
42 testes

Troquei jest por mocha e chai e as corridas voltaram para o modo de observação de cerca de 1 segundo e 10 milissegundos.

Troquei jest por mocha e chai e as corridas voltaram para o modo de observação de cerca de 1 segundo e 10 milissegundos.

Basicamente, você não leu meu último post. Você queria promover mocha/chai ... todos nós sabemos sobre isso ... Estamos tentando consertar a regressão da piada. Você pode ajudar a fazer isso [da minha postagem] ...can you try with micromatch 4... ou manter esses comentários inúteis fora do tópico. Desculpe ser direto, mas em algum momento não há outra maneira de dizer isso.

@nasreddineskandrani estou testando [email protected], mas ainda vejo uma execução extremamente lenta ao executar com o modo de relógio, qualquer ajuda seria muito apreciada.

@pachumon a correção não está presente em 24.8.0, tanto quanto eu entendi

você precisa definir uma dependência de jest para uma versão específica para remover o problema de desempenho (teoricamente) a correção estará por padrão presente em jest 25 => leia aqui para saber como um dev descobrir isso https://github.com/ facebook / jest / issues / 7963 # issuecomment -483985345

para definir a dependência (micromatch) para a versão onde a correção foi feita => você pode verificar aqui eu fiz um exemplo em um pequeno projeto
https://github.com/nasreddineskandrani/benchmark_jest/blob/master/jest_24_with_micromatch4/package.json

Adicione ao seu package.json : (deve usar yarn não npm )

...
  "resolutions": {
    "micromatch": "^4.0.0"
  }
...

Espero que isto ajude! e esperando por feedback

Meu tempo de execução de teste também aumentou de ~ 2,5 minutos em 23.6.0 para ~ 15 minutos em 24.7.1 e 24.8.0. Nosso servidor de CI está executando o Windows e observou um aumento similarmente grande no tempo de construção com esta atualização. Tentei a substituição de resolução de dependência de micromatch conforme mencionado acima por @nasreddineskandrani sem sucesso. Informe-me se houver algo que eu possa fazer para ajudar no diagnóstico.

@TomMahle, este é um newz muito ruim :( (a regressão da qual estamos falando no topo já estava em 23.6)
No momento, um projeto simples de 'amostra' mostrou bom desempenho. após a atualização da micromatch.
então precisamos de um projeto problemático real para depurar, seu projeto é privado? ou público?

Obrigado pela sugestão sobre micromatch @nasreddineskandrani , mas como @TomMahle acima, fixá-lo em ^4.0.0 também não pareceu melhorar o desempenho para mim. 😢

Eu descobri uma coisa estranha, porém, que pode ajudar a diagnosticar esse problema.

Tenho a capacidade de executar o jest no meu sistema Windows nativo, em um contêiner do docker com o diretório principal do aplicativo montado no meu sistema de arquivos Windows. A execução no modo de não observação parece ter um comportamento quase idêntico em ambos os sistemas, o que talvez sugira, como @thebearingedge sugeriu , que o problema central tem algo a ver com o sistema de arquivos NTFS, uma vez que meu contêiner docker está executando tudo, exceto o sistema de arquivos em uma VM linux.

No entanto, no modo de observação, as coisas são um pouco diferentes: as janelas nativas sempre funcionam lentamente conforme o esperado, mas o contêiner do docker apenas executa os testes lentamente na primeira execução . Assim que digo para executar qualquer suíte de testes pela segunda vez (por exemplo, pressionando p e inserindo um padrão), ele executa os testes em menos de um segundo (fazer o mesmo no Windows nativo leva de 3 a 4 segundos). A única desvantagem de usar o docker é que os eventos de alteração de arquivo não parecem se propagar do volume do meu Windows para o docker, então eu tenho que pressionar Enter manualmente para executar novamente o teste em vez de fazer jest fazê-lo automaticamente, mas acho que é não é relevante para o problema em questão.

@nasreddineskandrani. Infelizmente meu projeto é privado. Se houver alguma amostra de código menor (a configuração do jest?) Ou estatísticas que eu poderia fornecer, ficarei feliz em fazer isso. Todos os testes parecem ser dramaticamente mais lentos (apenas no Windows), então não acho que isso tenha a ver com os testes específicos.

Estou terminando uma coisa do docker que estou fazendo para meus sites pessoais -> depois (em uma semana) eu voltarei sobre isso.

@TomMahle
Vou tentar do meu lado ter um repo github com o problema que você descreve.

1. Quantos testes você tem?
2. você está ativando o modo dom para os testes?
3. é reagir ou angular?
   bônus:
4. você pode tentar reproduzir o problema em um repositório github para poder depurar?
   você pode garfo o meu: https://github.com/nasreddineskandrani/benchmark_jest
   Ou
5. talvez tente meu repo em sua máquina de teste? e ver os resultados? entre 23,6 e 24

Eu pensei que atenção suficiente foi dada aos mantenedores da micromatch, então isso já deve ter sido resolvido. Executar (assim escrever) testes de brincadeira no Windows é uma experiência muito desagradável no momento.

Mudei para mocha / chai desde então, mas estou surpreso que este problema ainda esteja sendo resolvido.

Esclarecimento

Eu usei --runInBand, mas parecia ter desacelerado um pouco os testes de unidade ainda mais em 0,2 segundos adicionais cada, com base no sentimento.

=> você tentou com v24? de v23 a v24, você verá uma boa melhoria SOMENTE neste cenário:
_no rerun com watch e apenas se você executar em um arquivo (não na primeira execução) _
-> 2/3 seg. Para 0,4 / 0,5 seg.
mas comparado ao mac eu nunca tentei ... então talvez ainda seja ruim ... mesmo com a melhoria atual

@SimenB

1. Eu considero # 7110 como regressões de velocidade Jest [v22 vs v23] no Windows para TODOS os cenários problemáticos.
   onde # 6783 é um deles

2. Posso considerar esse problema como: problema de velocidade para jest [Mac vs Windows] para TODOS os cenários problemáticos.

Tentei com as duas versões na época do post.

Acabei de criar um novo projeto com um teste com testes push de matriz simples e demorou mais de 10 segundos do início ao fim. O projeto está usando react / typescript, mas o arquivo de teste não é um arquivo de componente react, mas um arquivo normal como um .js. Gif abaixo para referência visual se torna melhor visualizar qual pode ser o problema:

Notei que a primeira vez que executo o teste mostra que o teste está estimado em 9 segundos. Depois de concluído, ele repete os testes aleatoriamente uma segunda vez até a conclusão.

Quando tirei aquela foto gif acima (que era a segunda vez dessa vez), o tempo estimado diminuiu um pouco e não fiz uma segunda tentativa. Não tenho certeza se esse é o comportamento de brincadeira esperado.

Aqui está um gif meu executando micromatch 4 com yarn em um projeto separado:

Usando o Windows 10 e as especificações do meu computador são:
AMD FX (tm) -8320 Processador de oito núcleos 3,50 GHz
16 GB de RAM
x64
SSD

Deixe-me compartilhar meu perfil aqui.
Especificações:

• Windows 10 Pro
• Nó 10.15.3
• Intel Core i7-4702MQ 2,2 GHz
• 8 GB de RAM
• x64
• SSD

Passos:

1. npx create-react-app my-app --typescript
2. mudar App.test.tsx
3. execute npm test

Perfil da CPU:

CPU-20190801T141211.zip

É esperado que 15 segundos sejam gastos apenas com os módulos necessários para um único componente e teste trivial do React?

Alguém com mais experiência em perfis de CPU pode dar uma olhada?

112 testes
windows 10
primeira execução 507 segundos
segunda corrida 23 segundos
sub-sistema linux
Primeira corrida 54 segundos
segunda corrida 29 segundos

85 testes
windows 10
primeira corrida 44 segundos
segunda corrida 15 segundos
sub-sistema linux
primeira corrida 26 segundos
segunda corrida 15 segundos

Kepro esses resultados são com micromatch 4?

Eu prefiro chat direto do que ter 1 milhão de mensagens aqui, está realmente se tornando um inferno acompanhar todas as questões relacionadas ao mesmo assunto.
Você pode entrar aqui. https://gitter.im/wearefrontend/jest-slow-windows
Eu estou nisso agora ...

O Gitter está bloqueado na VPN da minha empresa - se vocês, adoráveis ​​pessoas, pudessem postar atualizações significativas aqui, isso seria incrível <3

você ainda pode se conectar em casa para fazer algum código aberto: P e verificar
PS a dota game leva mais tempo para enfileirar agora você pode verificar gitter neste tempo;)
é onde está agora: nodejs / node # 28946

@nasreddineskandrani Você me pegou. Encomendei um novo macbook, por isso estarei fora de ação de código aberto até que ele chegue. Eu me recuso a realmente trabalhar na minha caixa do Windows de baixa qualidade no meu tempo livre: D

Parece que o problema mudou para o domínio do nó / C ++, que está um pouco (extremamente) fora da minha zona de conforto - mas vou fazer algumas pesquisas!

Oi alguma notícia sobre isso?

Como alternativa, você pode usar --runInBand se iniciar vários testes. O primeiro teste ainda demorará muito, mas os próximos serão rápidos.

Meu projeto levou 21.803s para executar todos os testes.
Agora com --runInBand leva apenas 7,412s

--runInBand para mim, apenas deixe-o ainda mais lento. 1200tests. Sem runinBand 70/50 segundos. Com --runInBand, seus 90 segundos em segundo são executados na melhor das hipóteses
No Linux é 5-8x mais rápido

Tente --maxWorkers = 4 então.

@ cino893 , não é uma solução :) tente encontrar a correção e não uma solução alternativa

Alguma notícia disso? Eu empilhei a versão 21 por causa desse bug. v22 é lento e v23 é ainda mais lento.
Vocês não acham que é um bug de alta prioridade?

Onde eu trabalho, não temos liberdade de escolher o SO nem de instalar o Ubuntu no Windows ou algo semelhante.

@gombek , você já experimentou a v25? A equipe do Jest fez muitas melhorias de desempenho em todas as áreas.

Olá, pensei em acrescentar algumas informações adicionais a esta discussão. O Jest é muito lento também quando executado dentro de um container Docker que possui o código-fonte e os testes compartilhados via volume do sistema host (Windows).

Tenho certeza de que essa desaceleração se deve às diferenças na forma como o Windows lida com os arquivos em comparação com os sistemas unix. No Unix, se um processo tiver um identificador de arquivo aberto que não bloqueie outros processos de ler esse arquivo. No Windows, um processo que contém um identificador de arquivo possui esse arquivo, desde que ele libere o identificador. Gostaria de olhar para o código Jest para a lógica de leitura de arquivos e, especialmente, quando e como os identificadores de arquivo são lançados. Um programa que se comporta bem deve, de qualquer maneira, liberar identificadores de arquivo imediatamente após ter feito seu trabalho. O executor de teste como Jest não deve ter nenhuma razão para segurar o identificador de arquivo por muito tempo.

@gombek , você já experimentou a v25? A equipe do Jest fez muitas melhorias de desempenho em todas as áreas.

Estou usando o Jest v25 no windows e ainda está lento

@pfftdammitchris Eu comparei suítes de teste bastante complexas no Mac + Windows e vejo algumas diferenças, principalmente em um cache frio. O Windows é notavelmente mais lento, mas quando está quente obtenho um desempenho semelhante entre os dois.

CONTUDO...

Uma coisa a ser extremamente cautelosa no Windows em particular são os programas intrusivos no nível do kernel como Antivírus / File-watchers como Carbon Black (ou outro software de monitoramento de arquivos em tempo real). Se você tem algo assim em execução, pode ver grandes ocorrências de desempenho ao executar o Jest. Estou falando sobre levar dezenas de minutos para executar os testes.

Trabalhei para uma empresa no ano passado, onde o mesmo conjunto de testes levou cerca de 30 segundos em um Macbook Pro e 20 minutos em um laptop Windows com esses programas de monitoramento de arquivos em execução.

Não tenho ideia do porquê, mas arriscaria supor que é algo a ver com identificadores de arquivo e como Jest usa algumas das APIs do sistema de arquivos node.js.

Tenho apenas cerca de 20 testes e acabei de fazer alguns cronogramas com jest --watch, tanto na corrida inicial quanto pressionando enter para refazê-los.

No Windows demorou cerca de 15 segundos em ambas as vezes, enquanto no Linux demorou cerca de 5,3 segundos na primeira execução e 2,3 segundos nas execuções subsequentes.

Tentei usar -t = "GARBAGE" para fazer com que todos os testes fossem ignorados. o do Linux demorou 1,5 segundos, mas o Windows ainda demorou 13, então me parece que não é a execução real dos testes que está demorando!

Ambas as máquinas estão usando a versão mais recente de node e jest, e o linux é na verdade uma VM rodando dentro do Windows usando hyper-v, então, mantendo-se iguais, eu esperaria que o Windows fosse mais rápido.

Tenho apenas cerca de 20 testes e acabei de fazer alguns cronogramas com jest --watch, tanto na corrida inicial quanto pressionando enter para refazê-los.

No Windows demorou cerca de 15 segundos em ambas as vezes, enquanto no Linux demorou cerca de 5,3 segundos na primeira execução e 2,3 segundos nas execuções subsequentes.

Tentei usar -t = "GARBAGE" para fazer com que todos os testes fossem ignorados. o do Linux demorou 1,5 segundos, mas o Windows ainda demorou 13, então me parece que não é a execução real dos testes que está demorando!

Ambas as máquinas estão usando a versão mais recente de node e jest, e o linux é na verdade uma VM rodando dentro do Windows usando hyper-v, então, mantendo-se iguais, eu esperaria que o Windows fosse mais rápido.

Sim. E se você montar os códigos-fonte no Linux VM do Windows e executar os testes, eles ficam tão lentos quanto no Windows. Isso implica fortemente que o problema está na lógica de tratamento de arquivos de Jest, como mencionei anteriormente.

Sim. E se você montar os códigos-fonte no Linux VM do Windows e executar os testes, eles ficam tão lentos quanto no Windows. Isso implica fortemente que o problema está na lógica de tratamento de arquivos de Jest, como mencionei anteriormente.

Percebi que, enquanto os testes estão sendo executados, a CPU está alta, mas o uso do disco não. Tinha a ver com o bloqueio de identificadores de arquivo, eu esperaria que fosse de baixa CPU (a menos que o jest esteja de alguma forma em um loop apertado esperando que os identificadores sejam liberados)

Eu vi os comentários de hevans90 sobre observadores de arquivos. Não tenho nenhum antivírus de terceiros instalado ou similar instalado, mas a desativação da proteção em tempo real integrada do Windows não fez nenhuma diferença perceptível.

Espero que isso ajude quem tem tempo para tentar depurar.

Portanto, confirmei hoje que o Windows Defender faz uma grande diferença.
Eu costumava ter um monte de exclusões, mas quando recebi meu laptop mais novo e mais rápido, não consegui de jeito nenhum descobrir por que a piada demorava mais de 10 minutos para executar um único arquivo.

Então me lembrei das exclusões.
Não posso dizer exatamente quais exclusões fazem a diferença, mas fiz o corredor descer para <15 segundos em vez de> 10 minutos

Encontrei uma essência com exclusões relevantes (embora vigorosas)
https://gist.github.com/darvell/edbc758b11ea4dcd7226b7c9f1821196
Também adicionei extensões de arquivo .ts .js .spec.ts .spec.js .tsx

Não posso dizer exatamente quais exclusões fazem a diferença, mas fiz o corredor descer para <15 segundos em vez de> 10 minutos

Hmm, acabei de experimentar e não pareceu fazer nenhuma diferença para o meu (veja bem, o meu não estava demorando minutos, então talvez estejamos tendo problemas diferentes)

Sempre tenho exclusões em vigor de qualquer maneira. E, na verdade, o IntelliJ Idea sugere automaticamente colocar o diretório do espaço de trabalho em exclusões e faz isso por você, se você permitir (você deve). Portanto, no meu caso, a lentidão não se deve ao Windows Defender ou a qualquer outro antivírus.

A diferença de desempenho é de 5 a 10 vezes em comparação com um Mac. PC é uma máquina de desktop poderosa (leia-se: muito mais rápido que o macbook). Todo o resto é rápido como um relâmpago, apenas Jest está sofrendo com esse problema.

alguma atualização sobre isso? ... estou experimentando a mesma coisa, cada teste leva muito tempo para configurar e carregar, mas depois que o primeiro é carregado, ele roda em velocidade normal ...

Também tendo esse problema. Um único arquivo de teste com um único teste hello world e leva cerca de 15 segundos para iniciar, mais outros 12 segundos para executar o teste.

👋 Vejo algumas respostas sugerindo que eles estão usando texto datilografado com jest - pode valer a pena dar uma olhada (se você também estiver usando ts-jest): https://github.com/kulshekhar/ts-jest/issues/ 908 # issuecomment -484043250

A mudança para mim foi de esperar 30 minutos para a brincadeira (sem cache) para começar a apenas alguns segundos.

Tenha em mente que configurar o sinalizador isolatedModules resultará em nenhuma verificação de tipo para seus arquivos de especificação (e na perda de algumas funcionalidades): https://github.com/kulshekhar/ts-jest/blob/master/docs/user/ config / isolatedModules.md

Só estou postando isso aqui porque pode ser útil para determinar se o seu problema é com jest.

👋 Eu vejo algumas respostas sugerindo que eles estão usando texto datilografado com jest - pode valer a pena dar uma olhada (se você também estiver usando ts-jest): kulshekhar / ts-jest # 908 (comentário)

A mudança para mim foi de esperar 30 minutos para a brincadeira (sem cache) para começar a apenas alguns segundos.

Tenha em mente que configurar o sinalizador isolatedModules resultará em nenhuma verificação de tipo para seus arquivos de especificação (e na perda de algumas funcionalidades): https://github.com/kulshekhar/ts-jest/blob/master/docs/user/ config / isolatedModules.md

Só estou postando isso aqui porque pode ser útil para determinar se o seu problema é com jest.

JavaScript puro aqui. Eu tenho esse problema não relacionado ao TypeScript.

FYI: https://github.com/kulshekhar/ts-jest/pull/1549 estará na versão alfa do ts-jest (possivelmente hoje). Qualquer pessoa que esteja usando ts-jest ajude a testar a versão alfa e nos dê alguns feedbacks para https://github.com/kulshekhar/ts-jest/issues/1115

Também tendo esse problema. Um único arquivo de teste com um único teste hello world e leva cerca de 15 segundos para iniciar, mais outros 12 segundos para executar o teste.

Acabei de executar o mesmo teste em um Mac. Demora cerca de 1.5s para iniciar, <1s para executar o teste.

Também usando JS, não TS aqui.

JavaScript puro com Jest também aqui. Eu tenho um poderoso laptop quad core com processadores Intel 10gen e todo o resto é extremamente rápido, mas [email protected] está levando 2-3 vezes mais no Windows vs Linux para executar alguns testes básicos.

Mesmo problema, cerca de 60 segundos para meus testes serem executados no Windows, e nenhuma IU é exibida nos primeiros 45 segundos ou mais. Executei exatamente o mesmo conjunto de testes na minha máquina Linux e levou 8 segundos para ser concluído.

O comentário de @Cellule acima acelerou dramaticamente as coisas para cerca de 15 segundos.

@ryanrapini seguiu o conselho de @Cellule (mas passou pelo Windows UI > Virus and Threat Protection > Manage Settings > Add Exclusions ) e viu que alguns testes passaram de 13 segundos para 6, então basicamente metade. Obrigado!

Alguém quer contribuir com uma seção mencionando o Windows Defender (ou AV em geral?) Na página de perguntas frequentes do site? https://jestjs.io/docs/en/trou troubleshooting

Posso confirmar que usar isolatedModules: true com ts-jest fez uma grande diferença na inicialização a frio (~ 10mins => 15seg)
Não testei o aprimoramento deles no alfa porque estou esperando o número 9457 ser abordado antes de atualizar para o jest 25

Olá a todos,

O mesmo problema aqui e nenhuma solução funciona para mim ...

Eu executo um código muito simples no qual atualmente tenho alguns testes.
É do "Curso de Reação Avançada" de Wes Bo.
Ele o executa no Mac e obtém uma resposta imediata de seu computador.

E para mim:

Suítes de teste: 2 ignorados, 15 aprovados, 15 de 17 no total
Testes: 6 ignorados, 37 aprovados, 43 no total
Instantâneos: 18 aprovados, 18 no total
Tempo: 5,869s
Executei todas as suítes de teste.

isolatedModules: true não muda nada no meu caso, ainda estou entre 5 e 6 segundos.
E quando eu começo o teste com qualquer opção, leva de 9 a 10 segundos.

Adicionar minha pasta dev nas Exceções do Defender também não fez nada:

Suítes de teste: 2 ignorados, 15 aprovados, 15 de 17 no total
Testes: 6 ignorados, 37 aprovados, 43 no total
Instantâneos: 18 aprovados, 18 no total
Tempo: 5.563s
Executei todas as suítes de teste.

Existe alguma boa opção no Windows?
Eu preciso ir para wsl2?

Olá a todos,

O mesmo problema aqui e nenhuma solução funciona para mim ...

Eu executo um código muito simples no qual atualmente tenho alguns testes.
É do "Curso de Reação Avançada" de Wes Bo.
Ele o executa no Mac e obtém uma resposta imediata de seu computador.

E para mim:

Suítes de teste: 2 ignorados, 15 aprovados, 15 de 17 no total
Testes: 6 ignorados, 37 aprovados, 43 no total
Instantâneos: 18 aprovados, 18 no total
Tempo: 5,869s
Executei todas as suítes de teste.

isolatedModules: true não muda nada no meu caso, ainda estou entre 5 e 6 segundos.
E quando eu começo o teste com qualquer opção, leva de 9 a 10 segundos.

Adicionar minha pasta dev nas Exceções do Defender também não fez nada:

Suítes de teste: 2 ignorados, 15 aprovados, 15 de 17 no total
Testes: 6 ignorados, 37 aprovados, 43 no total
Instantâneos: 18 aprovados, 18 no total
Tempo: 5.563s
Executei todas as suítes de teste.

Existe alguma boa opção no Windows?
Eu preciso ir para wsl2?

Você pode tentar aplicar minha solução e me dizer se ela faz alguma coisa? (na verdade a solução da Cellule, mas eu fiz isso por meio do menu em vez de executar um script)

Você pode tentar aplicar minha solução e me dizer se ela faz alguma coisa? (na verdade a solução da Cellule, mas eu fiz isso por meio do menu em vez de executar um script)

Como disse na minha mensagem, já fiz isso :)

Quer dizer, eu segui o que você fez, por meio do menu e tudo.

Também estou tendo esse problema no Windows. O teste em si é executado em <1 segundo, mas a configuração geral leva cerca de 15 segundos para ser executada. Eu tentei com v24 e v26, na verdade é um pouco mais lento na v26

Não tive sorte com nenhum dos seguintes (não melhorou o tempo de execução):

• adicionando --runInBand
• definindo maxWorkers
• adicionando .ts .js .spec.ts .spec.js .tsx exclusões a Virus and Threat Protection , conforme sugerido por @Cellule e @alessioalex

O mesmo problema no Windows aqui com vanilla javascript, bem como um novo projeto typescript. 2 segundos para executar 9 testes de unidade executados em <10ms usando mocha.

Isso é loucura!

Simplesmente instalei o jest globalmente e agora exatamente o mesmo projeto é executado em 0,9s em vez de 52 (!!!) segundos!
npm remove jest no projeto, então
npm install -g jest

Claro que gostaria de integrar o jest como dependência de desenvolvimento no projeto novamente. Alguma ideia de por que isso acontece?

Isso é loucura!

Simplesmente instalei o jest globalmente e agora exatamente o mesmo projeto é executado em 0,9s em vez de 52 (!!!) segundos!
npm remove jest no projeto, então
npm install -g jest

Claro que gostaria de integrar o jest como dependência de desenvolvimento no projeto novamente. Alguma ideia de por que isso acontece?

Isso definitivamente soa como um problema de scanner de vírus para mim. Ou seja, o diretório do seu projeto está no escopo da varredura de vírus, o que diminui a velocidade do gracejo para um rastreamento, mas o diretório npm global não está. Este é apenas um palpite.

Acabei de tentar a mesma coisa que @JPustkuchen e o desempenho vai de ~ 10s para <1 segundo.

Excluí minha pasta de projeto do Windows Defender, mas Jest ainda está lento.

Não sei se isso ainda está sendo trabalhado, mas noto que quando eu cometo um erro de digitação no código, os testes no modo de observação falham instantaneamente. O que me leva a pensar que não está realmente forçando um novo rastreamento de diretório antes de compilar o teste. Testes muito simples estão levando 10 segundos para mim também.

Eu gostaria muito que alguém pelo menos reconhecesse que isso é um problema. Como está agora, minha máquina de desktop Windows que tem bastante poder (leia-se: muito mais do que o macbook de meus colegas de trabalho) é aproximadamente 69 vezes mais lenta que o macbook ao executar testes! Isso está praticamente me forçando a não mexer no código do front-end, uma vez que é muito ineficiente para mim trabalhar neles devido aos testes de Jest serem executados tão lentos. Talvez tenhamos que nos afastar de Jest se isso não for corrigido. Todo o resto é rápido como um raio, mas os testes de Jest são extremamente lentos. O tempo é gasto em outra coisa do que realmente executar os testes, quando a lógica do teste real é executada, eles vão muito rápido.

Em uma nota mais positiva, gostaria apenas de dizer que tenho uma grande dívida de gratidão com esse bug. Foi a gota d'água que me fez decidir mudar para o Linux como meu principal fluxo de trabalho de desenvolvimento e nunca estive tão feliz. Não posso dizer que nunca voltaria porque às vezes tenho que trabalhar em projetos legados, mas com o ASP.NET core sendo multiplataforma, os motivos para reinicializar no Windows estão diminuindo o tempo todo.

Por favor, @ timrobinson33, vamos continuar no tópico. Não há razão para jest ser 68 vezes mais lento do que qualquer outro ambiente no Windows, considerando que o Node funciona bem em qualquer plataforma. Também devo acrescentar que não tive esse problema com nenhum outro executor de teste.

Eu testei com a v26.4.2 no meu repositório de referência jest github.
https://github.com/nasreddineskandrani/benchmark_jest
versão do nó em meu computador: v12.13.0

muito bem quando eu atualizo o teste simples (veja a imagem)! Para mim, o gracejo agora é correto para um teste simples.
Se você tiver um problema no seu trabalho. Você precisa tentar isolar o problema, pois por padrão está tudo bem.

@empperi você pode tentar meu repo de benchmark. exemplo com a pasta v26 e me diga quanto tempo leva para executar este teste em sua máquina? se não for 0,166 ms ou próximo a isso, você tem um problema do seu lado.

Eu testei com a v26.4.2 no meu repositório de referência jest github.
https://github.com/nasreddineskandrani/benchmark_jest
versão do nó em meu computador: v12.13.0

muito bem quando eu atualizo o teste simples (veja a imagem)! Para mim, o gracejo agora é correto para um teste simples.
Se você tiver um problema no seu trabalho. Você precisa tentar isolar o problema, pois por padrão está tudo bem.

@empperi você pode tentar meu repo de benchmark. exemplo com a pasta v26 e me diga quanto tempo leva para executar este teste em sua máquina? se não for 0,166 ms ou próximo a isso, você tem um problema do seu lado.

Como esperado, nenhuma diferença no desempenho da configuração do teste. É executado um pouco mais rápido do que no seu computador. Alterou sua configuração de teste para conter 100 arquivos de teste em __tests__ e esses também funcionam bem. Como nosso aplicativo usa react-scripts , também adicionei isso ao seu exemplo para verificar se isso poderia causar o problema real, mas nenhuma diferença no desempenho.

NO ENTANTO, tentei executar esses testes em WSL2 bash (contra o sistema de arquivos NTFS) e boom, tempo de execução quase 10x para o PowerShell bruto. Velocidade de E / S mais lenta é esperada em WSL2 contra NTFS, mas considerando o quão simples esta configuração é (apenas 100 arquivos de teste com um único teste em cada um), ela realmente não deve afetar tanto. Para referência, executei isso no bash WSL2:

time find . -name "*.js" -print | xargs cat
...(file content prints omitted)...
real    0m0.138s
user    0m0.030s
sys     0m0.000s

O que mostra que praticamente não leva tempo para ler o sistema de arquivos do WSL2. Para referência de comando semelhante no Powershell:

> Measure-Command { ls *.js | % { cat $_ } }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 49
Ticks             : 499000
TotalDays         : 5,77546296296296E-07
TotalHours        : 1,38611111111111E-05
TotalMinutes      : 0,000831666666666667
TotalSeconds      : 0,0499
TotalMilliseconds : 49,9

O que mostra que o desempenho está no mesmo estádio.

Portanto, com base nisso, eu diria que o problema pode ser causado como Jest usa E / S e isso está de alguma forma afetando drasticamente o desempenho no WSL2. Quando se trata do projeto que está me causando problemas, não é uma tarefa simples não exigir o bash devido a problemas no código e nos testes (não feitos por mim!). Considerando o fato de que WSL2 está ganhando popularidade, eu diria que este é um problema real que deve ser examinado.

Espero que isto ajude.

:editar:

Só por curiosidade, executei nosso conjunto de testes com --no-watch para ver se observar o sistema de arquivos no WSL2 afeta de alguma forma as coisas. A resposta é não, realmente não afeta muito.

Executar o benchmark na minha máquina Windows leva cerca de 1.6s. Não estou usando WSL.
Estou usando o antivírus AVG, mas adicionei exceções para o repositório e o executável do nó.
Meu disco rígido é um SSD.

A versão do nó é v12.16.1

Atualizar o teste aciona instantaneamente o observador de arquivos, mas o tempo real que leva para executar essa atualização é de cerca de 1s-2.4s.

Eu queria testar se o problema é o meio ambiente.

Eu estava mexendo neste repositório: https://github.com/kentcdodds/react-testing-library-course/tree/tjs

• Eu procuro npm test e todos os testes começam a ser executados no modo relógio.
• Eu pressiono 'p' para inserir um padrão para um arquivo e digito "tdd-02". Tenho mais de 3 segundos de tempo de execução.
  

Eu ficaria surpreso se Kent C. Dodds tivesse um ambiente bagunçado em seu curso pago, mas se ele tiver, você provavelmente poderá depurar lá:? Em seus vídeos funciona muito bem, acho que ele usa um Mac.

Devo notar algo muito estranho que não posso reproduzir novamente - tive alguns testes consecutivos que para um dos arquivos (tdd-02 ... js) executado por cerca de 0.1s, e para o arquivo ao lado dele ( tdd-01 ... js) - cerca de 3s. O código é quase o mesmo e usa as mesmas dependências. Portanto, copiei o código do arquivo de execução rápida e colei no de execução lenta e vice-versa. Os resultados foram os mesmos - o arquivo de execução lenta permaneceu lento e o arquivo de execução rápida permaneceu rápido, com os códigos reais trocados. Isso está ficando louco. Agora, os dois arquivos ficam lentos novamente (3-6s).

@Glinkis você pode tentar apertar enter após a primeira execução, ainda está mostrando 1.6seg? (acionar uma nova execução)

@SimeonRolev vou dar uma olhada no exemplo que você postou e ver que tipo de número eu obtenho com os mesmos passos (padrão ...)
atualizar:
try1: eu tentei como você e obtive 6 segundos quando tentei seus passos -> diminua para 3 segundos ao executar novamente o mesmo teste (pressione Enter)
try2: jest atualizado para 26,4 no repo de Kent -> 3 segundos primeira execução quase igual para nova execução
try3: Peguei index.spec.js arquivo do meu repositório de teste de benchmark e deixei cair no repositório de Kent. (excluindo todos os outros arquivos de teste) -> surpresa 2.8seg (MESMO JEST 26.4.2, MESMO COMPUTADOR, POWERSHELL, NODE_VERSION etc ... como meu teste ontem postou aqui)

Eu não entendo isso try3 ainda => ~ 3 seg em reprise em Kent repo para o meu arquivo, mas no meu repo cai para 0.300s em reprise (necessidade de alguém para depurar este)
editar: Kent deve ser o único a verificar isso: P

Pressionar enter faz com que o teste seja executado em cerca de 200ms.

@nasreddineskandrani Você tentou vice-versa? Quer dizer, copiar os testes do repositório lento para o seu? Mas não acho que o problema seja com o repo que postei. Como podemos ver claramente, muitas pessoas estão tendo o mesmo problema, eu estava postando um exemplo reproduzível.

@kentcdodds Você será nosso herói mais uma vez?

@SimeonRolev Em meu benchmark, não vejo o mesmo problema do repo de Kent. Você tem algo em Kent Repo. que causa essa lentidão => fora dela a brincadeira é mais rápida.

Esse problema do github está relacionado às janelas de desempenho do Jest vs macOS / Linux, uma vez que não atingiram o mesmo desempenho. eles não fizeram uma cláusula, eu acho. (é muito melhor agora do que há 2 anos com o jest v23)

Olá, estou tendo o mesmo problema aqui. Eu tenho uma máquina Windows e WSL. Copiei meus arquivos de projeto para WSL para testar esse comportamento. Aqui estão as execuções dos mesmos dois testes básicos:
Windows 10 (versão 2004):

WSL 2 (Ubuntu 20.04):

Os testes são muito simples:

O projeto é criado com CRA, então não há configuração para bagunçar as configurações, não adicionei nada em termos de Jest.
Os mesmos testes são executados extremamente rápido no mocha, quase instantaneamente. Estou tentando configurar um ambiente de teste para nosso projeto e gostaria muito de usar o Jest, mas parece que à medida que adiciono mais e mais testes, o conjunto de testes ficará cada vez mais lento, parece. Cada teste parece estar adicionando 0,8 segundos, o que é ridículo, já que eles não fazem nada. Algo está atrapalhando a execução de testes no windows e não sei o quê.
O problema era pior, um único teste demorava cerca de 15 segundos, mas quando adicionei --runInBand e, a situação pareceu melhorar um pouco, mas acho que ainda não é suficiente, considerando que o modo relógio mocha é instantâneo.

Yarn é a versão 1.22.5, todas as outras dependências do npm (como react e react-scripts) são as mais recentes.

Desativei o antivírus e o Windows Defender para ver se tinha algum efeito, mas não tem. Além disso, desativei a indexação da pasta do meu projeto, mas também sem sucesso.

Edit: Tentei pressionar Enter e os testes foram tão rápidos quanto no WSL:

Agora estou realmente confuso :)

Mas isso ainda parece muito lento, pois parece que cada teste leva 0,3 segundo, o que é muito, considerando que eles não fazem nada. Espero que esta suíte seja concluída em 0,1 segundos.

Edição 2: quando adicionei 100 testes ao meu conjunto de testes, levei cerca de 44 segundos para executá-los, mesmo se eu pressionar Enter para executá-los:

Os mesmos conjuntos de testes levam cerca de 9 a 10 segundos no WSL: