Jest: Testes de reação lenta

Olá, Tyron. Tive esse problema com mais de 20 segundos para um arquivo :)
O fato é que eu configurei para apenas executar 'jest' no diretório raiz. E há MUITOS subdiretórios que Jest estava verificando para testes. A especificação de um caminho para os testes foi reduzida neste momento mais de 10 vezes. E também tenho um pré-processador de café. Em package.json
"scripts": {
....
"test": "jest path / to / modules / to / test"
}

BTW, você está pré-processando café ou o quê? :)

Obrigado por entrar em contato comigo, @gothy. Estou usando JS regular com JSX. Estou apenas executando meus testes por meio do pré-processador JSX como o exemplo (https://github.com/facebook/jest/tree/master/examples/react). O exemplo também leva cerca de 2,5 a 3 segundos para ser executado. O exemplo do jQuery leva menos de um segundo. O pré-processador JSX deve levar muito tempo ao processar seus arquivos JSX?

Teste de reação

teste jQuery

Ah, eu não usei para JSX. Não posso dizer nada sobre este processador. Talvez seja realmente lento. Eu descobri meu problema com diretórios em um projeto real com um monte de coisas antigas :)

Tive um problema semelhante com o pré-processador Coffeescript. Acho que o problema aqui é que o pré-processador tenta processar suas dependências também. Se acontecer de você exigir muitas coisas, ele ficará mais lento.

Eu definitivamente também experimento testes lentos com jest :(

Estou experimentando a mesma coisa. Não acho que tenha a ver com o pré-processamento (o processamento JSX neste pequeno arquivo é rápido). Comentei todo o código no teste de exemplo, exceto uma das seguintes instruções de requerimento e o teste ainda leva 4 segundos. Assim que eu os comento, o teste leva 0.1s. Fiz algumas pesquisas e parece que o HasteModuleLoader está tendo que processar 490 pacotes necessários (_shouldMock ()) e não zombar deles quando você precisar dos react / addons.

var React = require('react/addons');

ou

var CheckboxWithLabel = require('../CheckboxWithLabel.js');

Removi o seguinte var React = require('react/addons'); e ainda executei os arquivos por meio do pré-processador. Eu consegui uma melhora de talvez 0,2 segundo. Se eu remover o pré-processador, obtenho os seguintes resultados:

Com o pré-processador JSX

Sem o pré-processador JSX

Eu prefiro Mocha ao invés de Jasmine e decidi configurar um gulpfile que iria construir o componente react e então executá-lo através do conjunto de testes mocha (trecho abaixo).

function buildScript(file, watch) {
  var bundler = browserify(file);
  var stream;
  bundler.transform(reactify);
  stream = bundler.bundle();
  return stream.on('error', handleErrors)
  .pipe(source(file))
  .pipe(gulp.dest(buildDir + '/'))
  .pipe(mocha({ reporter: 'list' }));
}

Ele ainda precisa pré-processar o arquivo JSX usando reactify, mas elimina a mensagem de aviso para testes lentos. Portanto, o tempo de execução ainda leva menos de 2 segundos, mas o teste real é de cerca de 32 ms. Ainda estou decidindo se vale a pena usar JSX.

Oh você está certo. Testei o exemplo do jest react sem usar JSX e passou de cerca de 4 segundos para 0,75 segundos. Me faz pensar se vale a pena usar JSX. Em um grande projeto, ele ficará lento muito rapidamente, a menos que eu tenha muitos pacotes diferentes. Eu me pergunto se o pré-processador é executado em todos os 490 requer e não apenas naquele único arquivo. Não há como levar 3 segundos para aquele componente simples.

De qualquer forma, eu realmente preciso que meus testes sejam rápidos para meu fluxo de trabalho. Eu ainda preciso descobrir como, pelo menos, executar uma única suíte. No jasmine, eu poderia usar "ddescribe" ou "iit" em vez de "describe" e "it" para executar um único teste ou suíte. Jest é TÃO legal, eu só preciso de um fluxo de trabalho rápido agora.

var React = require('react');

var CheckboxWithLabel = React.createClass({displayName: 'CheckboxWithLabel',
    getInitialState: function() {
        return { isChecked: false };
    },
    onChange: function() {
        this.setState({isChecked: !this.state.isChecked});
    },
    render: function() {
        return (
            React.DOM.label(null,
                React.DOM.input(
                    {type:"checkbox",
                        checked:this.state.isChecked,
                        onChange:this.onChange}
                ),
                this.state.isChecked ? this.props.labelOn : this.props.labelOff
            )
            );
    }
});

module.exports = CheckboxWithLabel; 

@jeffchan estava certo. Todo o código necessário é executado por meio do pré-processador, não apenas os arquivos JSX.

Parece que a solução mais rápida será usar gulp, watchify e reagir para processar apenas os arquivos JSX alterados enquanto você trabalha. Então, poderemos especificar apenas os testes que desejo executar. Dessa forma, os arquivos JSX são processados ​​apenas uma vez e eu tenho controle sobre quais testes são executados. Algo como isso seria muito bom para um fluxo de trabalho de teste.

gulp jest --tests "Checkbox*,*Form*"

O Watchify então observará todas as alterações das quais esses testes dependem e, em seguida, apenas processará as alterações e executará apenas os testes com os quais estou trabalhando.

@iamrandys concordo 100% com você. Jest e React são fantásticos, mas a compilação de JSX em JS é um grande obstáculo. Apenas curioso para saber como o Gulp resolverá o problema de ter seus arquivos necessários (não JSX) sendo executados através do pré-processador JSX? Você está sugerindo algo como o seguinte - http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/ ?

Sim, estou pensando em algum tipo de camada de cache com o plugin gulp em
trabalhando em

Em 11 de agosto de 2014 08:35, Tyrone Avnit [email protected] escreveu:

@iamrandys https://github.com/iamrandys Concordo 100% com você. Brincadeira e
React é incrível, mas a compilação de JSX em JS é um grande obstáculo. Somente
curioso como o Gulp resolverá o problema de ter os arquivos necessários (não
JSX) sendo executado por meio do pré-processador JSX? Você está sugerindo algo
como o seguinte? -
http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/
?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/facebook/jest/issues/116#issuecomment -51749798.

Exatamente, usar gulp e watchify é incrivelmente rápido com o react. Jogar dentro
gulp-livereload para atualizar seu navegador após cada alteração e você tem um
incrível ambiente de desenvolvimento. Você faz qualquer alteração, salva e quase
ver instantaneamente as mudanças em todos os seus navegadores abertos e todos os dispositivos. Agora eu
só preciso da mesma coisa para o meu TDD.

É mais ou menos assim, mas use reactify em vez de hbsfy.
https://gist.github.com/benhowdle89/9533185

Na segunda-feira, 11 de agosto de 2014 às 2h35, Tyrone Avnit [email protected]
escreveu:

@iamrandys https://github.com/iamrandys Concordo 100% com você. Brincadeira e
React é incrível, mas a compilação de JSX em JS é um grande obstáculo. Somente
curioso como o Gulp resolverá o problema de ter os arquivos necessários (não
JSX) sendo executado por meio do pré-processador JSX? Você está sugerindo algo
como o seguinte? -
http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/
?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/facebook/jest/issues/116#issuecomment -51749798.

Obrigado @iamrandys. Desenvolvido um boilerplate de componente de reação rápida que usa Mocha e Chai (Jasmine pode ser facilmente substituído). Os testes são extremamente rápidos e você obtém o benefício adicional do Livereload. Use como desejar.

De qualquer forma, eu realmente preciso que meus testes sejam rápidos para meu fluxo de trabalho. Eu ainda preciso descobrir como, pelo menos, executar uma única suíte. No jasmine, eu poderia usar "ddescribe" ou "iit" em vez de "describe" e "it" para executar um único teste ou suíte. Jest é TÃO legal, eu só preciso de um fluxo de trabalho rápido agora.

Definitivamente, você pode escrever it.only e acredito que também pode fazer describe.only .

Karma faz exatamente o que você deseja e tudo o que você precisa fazer é adicionar um
arquivo karma.conf para o seu projeto. Eu não sabia que o carma suportava reativar
e browserify. Agora você pode testar em todos os seus navegadores ao mesmo tempo.
Eu criei um PR para o seu projeto padrão.

https://github.com/iamrandys/react-component-boilerplate/tree/karma

Basta executar o 'npm test' e o karma iniciará seus navegadores e observará
alterar.

Na terça - feira, 12 de agosto de 2014 às 10:35, Tyrone Avnit
escreveu:

Obrigado @iamrandys https://github.com/iamrandys. Desenvolvido um rápido
reac-componente-boilerplate
https://github.com/TYRONEMICHAEL/react-component-boilerplate que usa
Mocha e Chai (Jasmine pode ser facilmente substituído). Os testes são extremamente
rápido e você terá o benefício adicional de Livereload. Use como desejar.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/facebook/jest/issues/116#issuecomment -51931532.

Use o seguinte preprocessor.js para evitar arquivos não JSX de transformação JSX. Como está, ele processa apenas .jsx arquivos que contêm o prefixo /** @jsx . Se você deseja transformar .js em JSX, apenas remova a primeira parte da condição if antes de || (de forma que apenas a condição src.slice ... permaneça).

// from http://facebook.github.io/jest/docs/tutorial-react.html
var ReactTools = require('react-tools');
var MAGIC = "/** @jsx";
module.exports = {
  process: function(src, file) {
    if (!/\.jsx$/.test(file) || src.slice(0, MAGIC.length) != MAGIC) return src;
    return ReactTools.transform(src);
  }
};

Ainda meio lento, no entanto.

Snippet interessante @sqs. Corrija-me Se eu estiver errado, mas ele ainda não teria que examinar cada arquivo e verificar se é necessário convertê-lo? Tive muito sucesso com o seguinte - boilerplate de componente de reação . Na verdade, os testes são executados muito rapidamente.

Muito agradável. Isso reduziu o tempo de 9.3s para 4.7s. Isso é para um único teste. Eu ainda terei que ficar com Karma onde é muito mais rápido (100 testes levam menos de um segundo). Além disso, o Karma observará as mudanças enquanto você trabalha e testará seu código em vários navegadores, mas eu adoro a simulação automática de Jest. Criar espiões manualmente usando rewireify é um trabalho extra, mas você tem controle total.

Sim, posso estar te entendendo mal, mas é o que eu quis dizer sobre remover a verificação de .jsx se você tiver arquivos .js com jsx e quiser detectar com base no cabeçalho pragma.

Enviado do meu iPhone

Em 28 de agosto de 2014, às 23:45, Tyrone Avnit [email protected] escreveu:

Snippet interessante @sqs. Corrija-me Se eu estiver errado, mas ele ainda não teria que examinar cada arquivo e verificar se é necessário convertê-lo? Tive muito sucesso com o seguinte - boilerplate de componente de reação. Na verdade, os testes são executados muito rapidamente.

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

Oi! Estou trabalhando em --watch por brincadeira e geralmente tentando fazer isso andar mais rápido. Apresentarei um relatório em breve.

a primeira execução para mim leva cerca de 5s (eu só tenho um teste, estou apenas começando). Depois disso, cada execução adicional leva cerca de 1,2-1,5s.

Parece que uma boa quantidade desse tempo é gasta carregando o cache de pressa (que para meu projeto já é um arquivo de 4 meg.

Estou ansioso para o trabalho de --watch , mas também estou me perguntando o que está acontecendo que requer 1,2 segundo de tempo de carregamento para executar um teste. Eu não sei nada sobre o que a pressa está fazendo e por que a piada está usando isso, então eu sou bastante ignorante.

O Haste suporta um tipo de formato de módulo CommonJS onde os nomes dos módulos são de nível superior ao invés de relativos. Isso significa que precisamos saber os módulos (e dependências) com antecedência antes de executar o programa, caso contrário, seria incrivelmente ineficiente percorrer o sistema de arquivos para procurar um módulo em cada require . No entanto, percebemos que a maioria das pessoas está usando o formato de módulo relativo (a la node.js) e queremos remover a dependência implícita do Haste (a menos que uma opção seja fornecida) e isso deve torná-lo mais rápido.

@amasad isso parece ótimo. Eu experimentei intern.js e ele executa um teste de unidade regular da linha cmd para terminar em alguns ms. Você acha que a piada poderia chegar tão rápido? E você já pensou em extrair a porção de travamento automático para que seja utilizável em outras estruturas, como jasmim ou moca?

Eu descobri que exigir arquivos (especialmente 'react / addons' e o módulo sendo testado) uma vez no callback de descrição, em vez de repetidamente em beforeEach ou it callbacks faz uma grande diferença.

Obviamente, estou usando o script de café e não o jsx, mas isso economiza tanto o trabalho do pré-processador quanto o trabalho de simulação automática de require chamadas.

__tests__/login_fields.coffee (3.013s) (ai!)

describe 'Login Fields', -> 
 beforeEach ->
    {TestUtils} = require('react/addons').addons
    LoginFields = require '../login_fields'
    ...
  it 'should have left animation states defined', ->
    {TestUtils} = require('react/addons').addons
    ...
  it 'should have a translateX value equal to enterStateStart.left', ->
    {TestUtils} = require('react/addons').addons
    ...
  it 'should call handleLogin on button click or enter press with the entered username and password', ->
    {TestUtils} = require('react/addons').addons
    ...
  it 'should call updateFields on all change events', ->
    {TestUtils} = require('react/addons').addons
    ...

mas fica muito mais rápido com ...
__tests__/login_fields.coffee (0.604s) (nada mal)

describe 'Login Fields', ->
  {TestUtils} = require('react/addons').addons
  LoginFields = require '../login_fields'
  # require other repeatedly needed modules here as well

  beforeEach ->
    # now you can use TestUtils to renderIntoDocument LoginFields here

  it 'should have left animation states defined', ->
    # and use TestUtils here
  ...

Meus testes duram 14 segundos, mesmo depois de usar todas as otimizações recomendadas até agora. Mesmo com 16 GB de RAM e SSD. Jest é totalmente inutilizável em seu estado atual. Desculpe, mudando para Karma.

Tive grande sucesso com karma, mocha, chai, sinon, rewireify e aliasify. Mais de 300 testes executados em 1/2 segundo. O melhor de tudo React é INCRÍVEL !!!!! A equipe ADORA isso e tem desenvolvido coisas realmente boas com ele. É tão limpo e fácil de manter. Grande diferença de tudo que já usamos.

Apenas corri para isso sozinho. Os testes são executados _REALLY_ devagar. O problema com os testes lentos é que os desenvolvedores os desabilitam ou os executam apenas parte do tempo. Alguma ideia do que esta causando isso? Como posso ajudar?

Eu tive exatamente este problema - os testes levaram cerca de 17 segundos para serem executados inicialmente e, em seguida, 4 segundos após o armazenamento em cache. Acontece que meu diretório de construção e módulos externos não foram excluídos corretamente. Definir a opção de configuração testPathDirs para apontar para o diretório de origem reduziu os tempos de execução para 0,5 segundos.

Isso funcionou para mim usando React v0.12 +:

var ReactTools = require('react-tools');


module.exports = {
  process: function(src, file) {
    if(!file.match(/\.react\.js$/)) return src;

    return ReactTools.transform(src);
  }
};

Também comecei a usar o Jest - apenas testando os módulos JavaScript regulares (sem JSX / React) e o Jest é terrivelmente lento. Eu amo a ideia de testes embutidos e simulação embutida, mas é tão dolorosamente lento que me faz sentir falta de Mocha. Não tenho certeza de qual é o culpado ... não é a busca na árvore de diretórios que está causando a lentidão. Se eu especificar o arquivo diretamente, ainda será muito lento.

Alguma ideia pelo menos sobre a causa da lentidão? (Não estou usando JSX / CoffeeScript; a simulação automática está desativada)

O exemplo original nunca funcionou para mim, pois o primeiro argumento sempre retornou verdadeiro.

var ReactTools = require('react-tools');
var MAGIC = "/** <strong i="6">@jsx</strong> ";
module.exports = {
  process: function(src, file) {
    if (src.slice(0, MAGIC.length) != MAGIC) return src;
    return ReactTools.transform(src);
  }
};

@culshaw @haihappen obrigado pelas boas soluções alternativas, encurte os testes 10s + para 2+. essas soluções alternativas me fizeram pensar que talvez devêssemos usar a extensão _.jsx / _. react.js para nossos arquivos react, acho que também pode ajudar ao usar reactify.

Para ser honesto ao passar por Grunt, eu ainda estava tendo tempos de +20s,
Reaja trabalhando com Karma e o tempo total é de cerca de +4/5 segundos.

Porém, tudo dentro de uma VM

Só para relatar sobre isso. Estivemos testando a reação com Karma / Mocha e estamos perto de 700 testes e leva cerca de 4 segundos para executar todos os testes. Temos que lidar com zombarias, mas vale a pena. React foi INCRÍVEL. Impecável e estável. Jogador desafiante! Nossa equipe não poderia imaginar usando outra coisa.

Eu nunca fiz Jest ser rápido. Estou usando mocha. Se Jest fosse rápido, eu
teria usado em vez disso.

Na quinta-feira, 5 de fevereiro de 2015 às 12h17, Gil Birman [email protected]
escreveu:

@iamrandys https://github.com/iamrandys você se importaria de explicar em
mais detalhes como você conseguiu fazer o jest tão rápido?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/facebook/jest/issues/116#issuecomment -73097182.

Obrigado @iamrandys, eu havia excluído meu "como você conseguiu ser rápido?" pergunta depois de perceber que eu havia interpretado mal sua postagem (mas você respondeu ao mesmo tempo) ... de qualquer maneira, é uma pena, acho que a piada ainda deve ser considerada não tão pronta para uso em produção.

as soluções alternativas / mudanças de @haihappen e @darcyadams me ajudaram a

Tenho o mesmo problema: fiz apenas 3 testes em um projeto pequeno e demoram 3 segundos.

Melhorar o desempenho está próximo ao roteiro do projeto?

BTW: eu encontrei uma maneira (bem hackeada) de reexecutar testes de unidade apenas para arquivos que foram alterados. Isso os torna muito rápidos novamente, já que geralmente há apenas um teste a ser executado. Eu coloquei aqui: https://gist.github.com/mik01aj/fefb7718331e5454b9d1

Strange Jest não foi mencionado no React.js 2015 conf.

testPathDirs parece ser o culpado. Especifique assim em package.json:

  "jest": {
    "unmockedModulePathPatterns": [
      "./node_modules"
    ],
    "scriptPreprocessor": "./preprocessor.js",
    "testDirectoryName": "tests",
    "testPathDirs": ["tests"]
  }

@adjavaherian tenha cuidado com isso se estiver usando simulação automática: https://github.com/facebook/jest/issues/176

Na verdade, espere que a simulação automática seja interrompida de maneiras sutis e frustrantes se seu testPathDirs não cobrir suas dependências.

Essas preocupações me fazem pensar que podemos estar fazendo algo errado com nossa configuração de teste. Posso estar errado aqui, mas até onde eu sei, estamos todos usando coisas como: var component = React.createFactory(require("component/path")) junto com outros módulos obrigatórios dentro do teste beforeEach . Certamente, isso não deve ser necessário para todos os testes. Quero dizer, uma fábrica deve produzir um componente novo todas as vezes. Se eu mover o require fora do bloco beforeEach , a velocidade do teste aumenta 10x. Infelizmente, nesse caso, alguns testes falham estranhamente e não sei por quê.

Não tenho certeza se isso ajuda. Pensamentos?

seria bom se o tempo de pré-processamento fosse deixado de fora do tempo de execução do teste relatado. É meio injusto ver vermelho quando a maior parte desse trabalho vem de uma etapa de transformação.

Oi, pessoal,

Estou tendo o mesmo problema. Tenho até alguns casos de teste que levam cerca de 1 minuto para serem executados :(

Não sei por onde começar a traçar o perfil do problema de desempenho, alguma dica?

ATUALIZAR

Corrigi esse problema que só apareceu em meu ambiente de VM (cf: http://stackoverflow.com/a/13703132). Agora os testes ainda estão mais lentos do que eu esperava, mas muito mais rápidos do que antes da correção do vagrant (60 segundos -> 6 segundos para meu traje de teste)

Se a velocidade ainda for um problema, sugiro mudar para Mocha. Tivemos muito sucesso com esse fork, que explica como configurar testes para implantações React simples a complexas. https://github.com/adjavaherian/mocha-react Executamos regularmente mais de 100 testes em cerca de 3 segundos.

Eu concordo que Mocha é o caminho a percorrer. Até quase 900 testes e leva cerca de 4 segundos.

Em 23 de abril de 2015, às 4:53 PM, Amir Djavaherian [email protected] escreveu:

Se a velocidade ainda for um problema, sugiro mudar para Mocha. Tivemos muito sucesso com esse fork, que explica como configurar testes para implantações React simples a complexas. https://github.com/adjavaherian/mocha-react Executamos regularmente mais de 100 testes em cerca de 3 segundos.

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

Mesma experiência, acabei de configurar o Jest com apenas um teste (usando JSX) e leva cerca de 3 segundos, isso é muito.

@iamrandys , você se importa em mostrar um exemplo de sua configuração? Parece a combinação perfeita.

@amasad Existe uma opção com Jest para construir um cache para arquivos compilados semelhante ao que o babel-loader permite na opção cacheDirectory? - https://github.com/babel/babel-loader#options

O que torna o gracejo lento para mim não é a compilação, mas sim a inicialização dos processos do pool de trabalho. Todos os meus testes passam em menos de 0,05 segundos, exceto os primeiros, que levam cerca de 4 segundos.
https://github.com/jeffmo/node-worker-pool
https://github.com/facebook/jest/blob/master/src/TestRunner.js#L376

@songawee Não quer mas quer enviar um PR para tê-lo como uma opção? Não acho que devamos tê-lo ativado por padrão, porque às vezes é impossível saber quando quebrar o cache. Por exemplo, se você alterar as opções do compilador, o cache deve ser redefinido. Outra opção é ter uma opção de reset-cache além do cache.

@doodzik, você tem certeza que é o pool de trabalhadores e não o node-haste informando e lendo os módulos?

@amasad O que fiz foi medir o tempo que cada etapa da execução de jest levava para ser concluída.
E o node-worker-pool foi a última instância em que os testes foram lentos.
Pode ser que minhas descobertas sejam apenas o sintoma e não a raiz do problema.
Mas não tive tempo de fazer uma análise adequada.

Meus testes atualmente são assim:

Meus testes de reação são lentos (aqueles na pasta de exemplos). Estou falando sobre os testes sem reação.

+1

Mesmo aqui. Os testes são muito lentos: decepcionado:

Achei que era só eu que enfrentava o problema. É a primeira vez que uso o Jest e também não obtenho resultado de teste rápido. Quer saber como o Facebook faz o teste usando o Jest?

Minha pergunta sobre as melhorias do Jest para os caras do React na sessão de perguntas e respostas da conferência React Europe - https://youtu.be/CRJZBZ_-6hQ?t=363

Mudou para Mocha + Sinon. Nunca estive mais feliz.

Em 31 de agosto de 2015 às 17:45, Alan Rubin [email protected] escreveu:

Minha pergunta sobre Jest to the React na conferência React Europe Q&A
sessão - https://youtu.be/CRJZBZ_-6hQ?t=363

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/facebook/jest/issues/116#issuecomment -136394910.

Eu tenho o mesmo problema. Os testes de Jest levam muito tempo e o tempo de execução varia. Se eles deveriam ser executados em paralelo ou em apenas um processo (--runInBand), não importava. Parece não ser uma contenção de recursos entre os processos de trabalho.

Criei alguns despejos de CPU com o criador de perfil v8 (https://github.com/node-inspector/v8-profiler) e descobri que a maior parte do tempo parece ser gasta simulando módulos. Ou seja, 25% do tempo de execução do meu teste de unidade é gasto em jest-cli / src / lib / utils.js # runContentWithLocalBindings.

alguma atualização de desempenho? acabei de pegar jest com es6 e babel-jest, mas executando 2 testes simples em> 10 segundos :-(
tentei muitas ideias deste tópico para acelerar, mas nada funcionou ...

Estaremos nos concentrando nisso em breve. Estamos um pouco sobrecarregados com o trabalho de brincadeira agora, mas estamos empenhados em torná-lo mais incrível.

A comunidade poderia ajudar em alguma tarefa?

+1

A maior ajuda agora seria melhorar a documentação, o site e resolver os problemas e ajudar as pessoas no código aberto.

Uma coisa que fizemos para acelerar nossos testes JEST no pipeline de construção foi substituir nossa máquina de núcleo único por uma de vários núcleos. Por padrão, o jest gera tantos trabalhadores quanto os threads de hardware estiverem disponíveis. Se não estiver disponível, você pode jogar manualmente com '-w' (maxWorkers). Você pode ganhar um aumento de velocidade também em um único núcleo.

No final das contas, descobrimos que os módulos de simulação são muito caros (veja meu comentário acima) e causa a maior parte do tempo de execução.

Brincadeira com es6 para mim é completamente inutilizável. leva mais de 10 segundos para iniciar e, em seguida, leva 2s para executar o único teste que tenho no momento. Eu esperava muito mais, voltando ao carma :(

No momento, estamos trabalhando para substituir o node-haste por um novo resolvedor de módulo, o que deve corrigir esse problema.

Olá a todos. Há alguma notícia sobre esse assunto?

Olá, o Jest é adequado para testes não React? Gostaria de ter um padrão comum para aplicativos de reação e não reação em nossa equipe.

Jest é um executor de testes universal e você não precisa de forma alguma usar o React. :) Basta dar uma olhada em um dos exemplos!

Olá a todos, algumas informações realmente interessantes aqui. Também estou tendo problemas com a lentidão dos testes. Atualmente, tenho 13 testes que levam cerca de 15 segundos para serem executados.

Descobri que adicionar "testPathDirs": ["<rootDir>/path/to/tests/"] ao nosso arquivo packages.json ajudou a melhorar o tempo de inicialização consideravelmente.

@cpojer Você tem uma atualização para nós sobre o novo e melhorado resolvedor de módulo? Eu realmente espero que esta seja a chave para fazer os testes rodarem muito mais rápido

Este trabalho está acontecendo em # 599.

Obrigado @cpojer 😀
Estou ansioso para ver o Haste2 concluído

Os mesmos testes usando mocha rodaram em 44ms para mim, onde o jest levou 6 segundos completos.

Levei cerca de 15 minutos para mudar meus 6 arquivos de teste iniciais usando jest para usar Mocha , jsdom e sinon .

Boas notícias a todos, estou integrando o # 599 hoje e isso deve acabar com a inicialização lenta, finalmente.

Ok, isso finalmente deve ser corrigido no Jest 0.9. Desculpe que demorou tanto, mas havia um pouco de palhaçada em Jest :)

Consulte https://github.com/facebook/react/pull/6052 sobre como os próprios testes React foram acelerados. Se você gostaria de tentar essa melhoria, verifique os comentários em # 599. Ele está atualmente marcado como jest-cli@next até para ver se há algum bug que as pessoas de código aberto possam encontrar. Vou encerrar este problema como resolvido.

npm install jest-cli@next se quiser executar esta nova versão (em vez de jest@next @cpojer)

ah sim, eu sempre cometo esse erro :) Eu editei meu comentário original.

@cpojer após atualizar usando npm install jest-cli@next Estou tendo problemas ao especificar dontMock . Quer dizer, antes da atualização (usando [email protected]) esta linha funciona corretamente:

jest.dontMock('../../../../fixtures');

então, após a atualização para 0.9.0, a mesma chamada resulta no módulo sendo simulado

@steinbachr que provavelmente deveria entrar em um problema separado. Seria ótimo se você pudesse fornecer uma reprodução, não vi esse problema surgir no FB!

obrigado @cpojer , problema criado aqui