Você quer solicitar um recurso ou relatar um bug ?
Reportar um bug .
Qual é o comportamento atual?
Chamar console.log
usando o testEnvironment padrão de jsdom
não imprime no stdout.
Se o comportamento atual for um bug, forneça as etapas para reproduzir e uma demonstração repl.it por meio de https://repl.it/languages/jest ou um repositório mínimo no GitHub que possamos yarn install
e yarn test
.
yarn test
testEnvironment
Jest para node
yarn test
Qual é o comportamento esperado?
Eu esperaria ter console.log sempre gerando saída enquanto meus testes estão sendo executados.
Forneça sua configuração exata do Jest e mencione seu Jest, nó, versão do yarn / npm e sistema operacional.
Veja package.json
e yarn.lock
no repo para versões de pacote. Estou executando o node 7.3.0 e o yarn 0.18.1
Acabei de testar isso usando repl.it: https://repl.it/EwfT/0
A boa notícia é que funciona conforme o esperado e as saídas console.log. Eu tentei fazer o downgrade da minha versão de gracejo para 17.0.3, ainda estava vendo os mesmos problemas. Instalado nvm
para testar com o nó v6.9.2, e hurray console.log funciona com jsdom, então estou assumindo que o problema está relacionado ao nó v7.
Obrigado por relatar isso, mas isso é uma duplicata de # 2166 e acontece no Nó 6 também.
@thymikee Por que isso é uma duplicata de # 2166? Nesse cenário, console.log
não produz nada. Estou tendo esse problema com o Node v4. O frustrante é que estava funcionando bem hoje cedo e, com 0 alterações em meu ambiente, não recebo mais console.log
saídas em meu terminal.
@thisissami parece que seu teste ou código não está rodando. O conjunto de testes de Jest passa no nó 4 e nó 6, o que garante que a impressão do console funcione bem e estamos trabalhando em uma correção para 7.3.
@cpojer - Meus testes passam / falham corretamente - apenas console.log
mensagens não aparecem. Descobri isso ao tentar descobrir quais são as propriedades de um objeto específico console.log
ing e não vendo nenhuma saída. Eu adicionei muitas instruções console.log
e nenhuma está aparecendo em meu terminal agora. = / Atualmente estou revertendo para Jest v17
para ver se isso muda alguma coisa.
Se estava funcionando hoje cedo para você e não está mais, você deve ter feito uma atualização ou quebrado algo sozinho. Não publicamos um lançamento de Jest em duas semanas.
ok, então a única coisa que mudou em meu código de teste é que adicionei um comentário de várias linhas após o código que deveria ser executado (como uma referência para mim). Vou ver se remover isso faz diferença.
@cpojer Não sei o que dizer, não vejo nada de errado no meu código de teste, mas nada está sendo enviado para o stdout:
import React from 'react';
import {shallow} from 'enzyme';
import FundPercentage from '../../src/reactClasses/fund_percentage';
console.log('cmon');
describe('Normal Percentage', () => {
console.log('do this');
const percentage1 = shallow(
<FundPercentage percentage={0.5}/>
);
const percentage2 = shallow(
<FundPercentage percentage={0.26}/>
);
it('should work', () => {
console.log(percentage1.childAt(0));
expect(0).toBe(1);
});
});
O teste falha, conforme o esperado, então sei que está funcionando. Minha configuração em package.json
é realmente simples, apenas:
"jest": {
"collectCoverageFrom": [
"src/*.jsx"
]
}
Jest funcionou normalmente, sem bandeiras extras anexadas. Mesmo problema com Jest v17 e 18.
Não mudei nenhum arquivo além deste durante toda a tarde. Acabei de entender como enzyme
funciona gerando várias coisas em stdout
e, depois de começar a adicionar expects
, o console.logs
parou trabalhando quando eu precisava deles novamente, e agora eles não funcionam de jeito nenhum - não importa o que eu tenha no teste. Eu também não mudei nada em meu ambiente (além de fazer o downgrade agora para a v17), o que certamente é confuso.
Parece que você atualizou para o nó 7.3. Temos algumas soluções para isso. Observe que este rastreador de problemas não é um fórum de ajuda; use stackoverflow para perguntas :)
Estou usando o node v4.4.7 e, no que me diz respeito - não ter nada mostrado no stdout ao usar console.log
é um problema. Não estou tentando obter ajuda com a codificação, estou relatando o que parece ser um bug para mim. A única outra coisa que mudou é que eu tinha vários arquivos de teste em execução antes, e agora apenas um. deixe-me ver se reativar os outros testes faz com que console.log
saídas apareçam novamente.
@cpojer Quase certo que vocês têm um bug aqui.
Ter 3 testes executados (como em 3 arquivos diferentes com .test.js
, com 2 desses arquivos sendo exemplos de seus tutoriais) funciona sem problemas. Meu teste (copiado acima) renderiza todos os console.logs.
Ter apenas 1 teste executado (também conhecido como renomear .test.js
para .teast.js
em 2 dos arquivos) resulta em nenhuma saída console.log sendo renderizada.
Vou continuar executando um segundo teste arbitrário para ver a saída de que preciso, portanto, atendo às minhas necessidades pessoais - mas isso deve ser resolvido imediatamente, presumindo que seja reproduzível em outro lugar.
O conjunto de testes de Jest testa esse comportamento no nó 4, nó 6 e nó 7.3. Funciona para 4 e 6, mas foi quebrado em 7.3. Estou corrigindo isso para o nó 7.3 e publicarei uma nova versão do Jest em breve: https://github.com/facebook/jest/pull/2464
Se o próprio conjunto de testes de Jest usando o nó 4 falhar para você, provavelmente algo está errado com sua configuração.
Clonando o repositório e experimentando agora.
Tudo passou, exceto por esses 3 testes. Não tenho certeza de quais implicações isso pode ter. Você tem todas as informações de quais são os erros relacionados ao console.log que estou tendo, assim como a imagem abaixo. Se isso não é um bug de brincadeira, então que seja. No entanto, parece estranho para mim que não fazer nada a não ser seguir os guias resultaria em um cenário em que não consigo ver meus logs ao executar apenas um arquivo de teste.
Isso apenas indica que você não tem o mercurial (hg) instalado, não relacionado ao seu problema. Parece que o conjunto de testes passa para você e como disse; testamos explicitamente o comportamento de registro no conjunto de testes, portanto, deve haver algo errado com seu código ou configuração.
Ok legal - obrigado pelo seu feedback. Você tem alguma ideia do que pode estar fazendo com que ele funcione quando há vários arquivos, mas não quando há apenas um? Se não houver um "ah, isso às vezes causa um problema como esse" óbvio que vem à sua mente - não se preocupe, vou garantir que sempre haja pelo menos 2 arquivos em execução. :)
Estou enfrentando o mesmo problema, console.log não está gerando para mim agora (e anteriormente era cerca de uma hora atrás). Estou usando o nó 6.9.1 e também habilitando o sinalizador --forceExit. Quando não tenho esse sinalizador habilitado, a saída console.log é exibida.
No entanto, tenho outro script de teste que utiliza o sinalizador --forceExit e o console.log aparece, portanto, não posso dizer que o sinalizador --forceExit esteja causando esse comportamento.
Como @thisissami está fazendo, tenho o problema de registro apenas quando tento testar um único arquivo.
Eu estava tendo o mesmo problema, mas descobri que era devido à execução de jest via jest-cli (jest.runCLI) em gulpfile.js e estava engolindo a saída de console.log. Se eu executar o jest diretamente, vejo a saída do console.
Agora estou tendo um comportamento estranho, que ainda não consigo isolar em um caso de teste simples, caso contrário, eu arquivaria um novo problema.
1) Jest faz um teste
2) Jest exibe as instruções console.log (não pisque aqui)
3) Jest rola para cima um número arbitrário de linhas, que às vezes cobre todas as linhas console.log, às vezes algumas e às vezes todas.
4) Jest executa o próximo teste (as linhas console.log do teste anterior desaparecem).
jest v18.1.0
Como não posso isolar isso em um teste simples, acho que tem a ver com a execução de um teste assíncrono mais complexo.
Estou tendo o mesmo problema, me pergunto se é a saída substituindo outra saída. Ocasionalmente, vejo algo assim:
É como se um processo gerasse um erro (tipos de prop com falha), mas ele apenas é escrito pelos logs de saída do teste.
Mais:
E às vezes, se eu Ctrl
+ c
enquanto os testes estão em execução, vejo os logs do console que não veria se deixasse os testes terminarem.
Versões
Jest: 17.0.1
Nó: 6.6.0
NPM: 3.10.3
macOS: 10.12.2
Terminal: 2.7.1 (e também em iTerm2 3.0.13)
Script (em package.json
): jest /src/main/js --watch
ou jest /src/main/js --coverage
ou jest --watch --onlyChanged
têm o mesmo comportamento.
@davidgilbertson isso acontece na v18.1?
Eu tentei 18.1.0
e parece ainda mais bugado. E ainda vejo coisas assim:
Não consigo escolher nenhum padrão em particular, mas algumas coisas aconteceram (tenho um console.warn('----------------')
em um dos meus componentes.)
ctrl + c
, vejo alguns logs do console. Mas se eu fizer o mesmo e não interromper, os logs do console não serão visíveis.jest /src/main/js --watch
uma vez e, em seguida, bato em a
para executar novamente, ele coleta uma série de testes legados em um diretório src/main/assets/legacy
- não correspondendo ao glob.jest --watch
(todos os meus testes terminam em .test.js
ou .test.jsx
). Portanto, acertar 'a' no modo de observação parece ir a qualquer lugar, incluindo um antigo teste de jasmim chamado src/test/js/spec/categoryselector/spec.js
. Acertar Enter
parece ter feito o que eu esperava.Será que todos os erros lançados por adereços ausentes causam esse problema? Tenho que manter ctrl+c
ing a saída para tentar detectar esses erros antes que eles sejam sobrescritos.
Também não funciona para mim (jest 19.0.1, nó 5.12). Curiosamente, ele funciona em outro projeto com a mesma configuração. Não tenho certeza de como depurar os testes do Jest, então poder ver algumas mensagens do console seria muito importante, eu acho.
Você já tentou usar o sinalizador jest --runInBand
para ver se isso resolve o problema executando testes em série? Alguém mencionou isso para mim, mas não teve oportunidade de testá-lo.
O sinalizador bail
evita que os logs do console sejam impressos.
Eu vou tentar. O que é um pouco enervante é que, no mesmo projeto, algumas instruções de log do console estão sendo geradas no console, outras não. Infelizmente, aqueles que tentei adicionar onde um caso de teste está falhando não obtêm saída (tentei adicionar em todos os lugares no caso de teste, na unidade testada, etc., sem sucesso). Portanto, não acho que isso possa ser apenas um sinalizador, pois o comportamento não é conciso. É um projeto nativo reactivo, seguindo o layout padrão aliás.
Nada disso parece ajudar. O sinalizador --bail apenas impede que outros testes sejam executados (o que está causando o problema é o último de qualquer maneira, no meu caso), e --runInBands não parece ter nenhuma diferença observável. Jest executa os arquivos atualizados aliás, portanto, se eu inserir uma instrução console.log, o rastreamento de pilha de erros mostra o erro proveniente do número da linha atualizado. É só que o log do console não acontece. Uma vez que é difícil / impossível depurar esses testes em um navegador (por favor, corrija-me se este não for o caso), console.log é absolutamente vital para corrigir alguns problemas nos testes.
Parece que este caso de teste não estava sendo executado de fato. Havia um TypeError (acessando uma propriedade em um undefined). O que me enganou é que realmente vi o rastreamento de pilha no console, o que sugere que ele está sendo executado. Portanto, ver o rastreamento, mas não ver a mensagem de log, não fez sentido :) Alguém sabe por que isso é feito dessa forma, então, se um teste falhar com um erro de tempo de execução, os logs não serão exibidos como parece? (Só para ficar claro, quero dizer logs que aconteceram até o ponto de erro, obviamente não me refiro a logs após o erro :))
Em meu ambiente, eu tinha verbose: true
definido nas opções de jest em package.json
. Alterar isso para falso (ou removê-lo) corrigiu o problema para mim. Todos os meus logs de console são exibidos agora.
Isso está em 18.1.
Para qualquer outra pessoa com esse problema, verifique todas as dependências adicionadas recentemente. Comecei a ter problemas depois de adicionar mock-browser
em uma tentativa de simular objetos do navegador. Aparentemente, ele substitui global
por seu próprio objeto.
package.json (configuração jest)
"jest": {
"testEnvironment": "node",
"moduleFileExtensions": [
"js",
"json"
],
"moduleDirectories": [
"node_modules",
"src"
],
"transform": {
"^.+\\.js$": "babel-jest"
},
"roots": [
"<rootDir>/__test__"
],
"setupFiles": [
"<rootDir>/__test__/test-setup.js"
],
"moduleNameMapper": {
"client": "<rootDir>/src/client",
"common": "<rootDir>/src/common",
"server": "<rootDir>/src/server",
"!CONFIG": "<rootDir>/config/env/test.js",
"\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$": "<rootDir>/__mocks__/file.js",
"\\.(css|less)$": "identity-obj-proxy"
}
}
test-setup.js
const mockBrowser = require('mock-browser').mocks.MockBrowser;
const MockBrowser = new mockBrowser();
global.APP_CONFIG = require('!CONFIG').default;
global.__DEVELOPMENT__ = false;
global.__TESTING__ = true;
global.__PRODUCTION__ = false;
global.document = MockBrowser.createDocument();
global.window = MockBrowser.createWindow();
global.localStorage = MockBrowser.getLocalStorage();
test-setup.js
Comentando os mock-browser
bits ...
// const mockBrowser = require('mock-browser').mocks.MockBrowser;
// const MockBrowser = new mockBrowser();
global.APP_CONFIG = require('!CONFIG').default;
global.__DEVELOPMENT__ = false;
global.__TESTING__ = true;
global.__PRODUCTION__ = false;
// global.document = MockBrowser.createDocument();
// global.window = MockBrowser.createWindow();
// global.localStorage = MockBrowser.getLocalStorage();
console.log
funciona bem.
Por que este problema foi encerrado? Obviamente, não é uma duplicata de # 2166
Vou adicionar meus $ 0,02 porque acabei de encontrar isso.
Emitir:
jest --watch --verbose
(v19.0.2)console.log
instruções não aparecem, nem durante a execução do teste ou no resumo_.reduce
: todas as instruções console.log
dentro deste bloco não são console.log
fora do bloco de redução são mostradas . Verifiquei por outros meios (cobertura, resultados de teste) que o corpo redutor está de fato sendo acionado. Isso é estranho, já que não estou fazendo nada assíncrono / promessa com base nesta parte do código, não consigo entender por que a chamada de redução afetaria alguma coisa.--runInBand
, vejo todas as instruções console.log
."testEnvironment": "node"
, não jsdom
Os comentários a seguir parecem estar relacionados ao meu problema:
https://github.com/facebook/jest/issues/2441#issuecomment -273643521
https://github.com/facebook/jest/issues/2441#issuecomment -278202180
É muito rápido, mas parece que os console.logs estão realmente sendo atraídos para a tela e, em seguida, substituído.
Acabei de confirmar com um vídeo que console.log
está de fato sendo desenhado na tela por ~ 0,2s antes de ser desenhado.
Executar --watch
sem --verbose
parece corrigir isso.
Passei 10 minutos tentando obter um caso de reprodução isolado, mas não consigo fazer isso. Provavelmente só se manifesta com grandes (bem,> 1) suítes de teste.
Você pode ver o comportamento aqui:
Antes de console.log
console.log - mostrado por uma fração de segundo (<0.2s)
Depois que o console.log for pintado
Este problema é realmente uma merda, perdendo muito tempo com este problema e nada parece funcionar. Eu escolhi uma piada porque pensei que os engenheiros do Facebook tinham um conjunto de testes decente e agora isso ...
É por isso que não gosto de Jest. Não importa o que você faça, eles limparão seu console e se recusarão a mostrar quaisquer declarações de console e, então, de alguma forma aleatória, eles aparecerão, até que você tenha um erro que precise corrigir, caso em que farão o possível para ocultar todos declaração de log para que você não possa corrigi-lo.
Por que você simplesmente NÃO PARA de tentar ocultar a saída do console dos desenvolvedores? Se eu quiser rodinhas, usarei a Angular 1!
Isso é bastante agressivo, @halis. Estamos fazendo isso porque Jest paraleliza os testes e muitos testes podem ser registrados no terminal ao mesmo tempo, o que significa que a saída de Jest se torna inútil. Na verdade, costumávamos fazer isso. Se você estiver usando --verbose
, não armazenamos nada em buffer e gravamos diretamente no console.
Se isso não funcionar para você, talvez você possa nos ajudar enviando um PR para Jest e melhorando esse comportamento.
Desculpe, estava tendo um dia muito ruim na sexta-feira e estava frustrado. Não há razão para descontar em você, você está apenas tentando ajudar.
Eu encontrei o sinalizador --verbose na sexta-feira, que me deu saída suficiente para corrigir meus problemas.
Mais uma vez, desculpe por ser tão idiota sobre isso.
Isso é ótimo. Não deixe que as ferramentas JavaScript estraguem as suas sextas-feiras 😀
Alguma novidade sobre isso? como mostrar console.log?
comportamento muito interessante, depois de bater minha cabeça algumas vezes (mais como várias vezes) descobri que --verbose é de fato o culpado por não ter o console.log impresso.
Minha melhor solução foi criar outro script em package.json que não tenha sinalizador verbose envolvido quando quero alguma mensagem impressa em meu console. Eu realmente apreciaria se vocês consertassem isso logo
Este problema é realmente muito chato, pois torna difícil / impossível depurar testes usando console.log (eu sei .. old school mas ainda conveniente).
Para mim, usar as opções --runInBand
fez minhas declarações de log aparecerem.
EDIT: Tenho certeza de que está relacionado à forma como os resultados são exibidos na tela ... uma opção seria ter um repórter 'fictício' que simplesmente não tenta uma renderização extravagante. Outra opção seria deixar o desenvolvedor escolher um repórter como o mocha faz.
É pior do que não mostrar os registros:
Se eu tiver qualquer forma de erro em um teste assíncrono, não apenas não vejo as mensagens de log, mas os erros expect
também ficam ocultos e as exceções são eliminadas.
test('async', (done) => {
setTimeout((() => {
expect(1).toEqual(2);
throw new Error();
done();
}), 1000);
});
Em nenhum lugar meu teste expect
exibido.
`` ``
Tempo limite - o retorno de chamada assíncrono não foi invocado dentro do tempo limite especificado por jasmine.DEFAULT_TIMEOUT_INTERVAL.
at Timeout.callback [as _onTimeout] (../../../../../../../../usr/local/lib/node_modules/jest/node_modules/jsdom/lib/jsdom/browser/Window.js:523:19)
at ontimeout (timers.js:386:14)
at tryOnTimeout (timers.js:250:5)
at Timer.listOnTimeout (timers.js:214:5)
`` ``
Nem runInBand
nem verbose:false
help.
Eu tenho uma configuração trivialmente simples ( babel-jest
).
@richburdon para testes assíncronos usando done
callback, você precisa cobrir o caso de falha com done.fail()
@thymikee obrigado pela resposta rápida. eu não sei o que você quer dizer embora. você pode modificar meu teste e / ou apontar para documentos. Muito obrigado.
test('async', (done) => {
setTimeout((() => {
expect(1).toEqual(2);
throw new Error();
done();
}), 1000);
});
test('async', (done) => {
setTimeout((() => {
expect(1).toEqual(2);
try {
throw new Error();
} catch (error) {
done.fail(error);
}
done();
}), 1000);
});
Eu entendo que isso não é o ideal, mas é assim que funciona atualmente. Vale ressaltar, que não é um problema, quando a função testada retorna uma Promise . Existem alguns problemas afetados por esse comportamento, como https://github.com/facebook/jest/issues/2136 ou https://github.com/facebook/jest/issues/2059. Se você tiver uma ideia sobre como melhorá-lo, adoraríamos revisar um PR e torná-lo realidade.
Mas este não é um assunto relevante para discutir, você pode postar suas idéias em outro lugar.
@thymikee , meu exemplo não foi bom, pois setTimeout
tem problemas relacionados a promessas que não têm nada a ver com brincadeira ...
Vale ressaltar, que não é um problema, quando a função testada retorna uma Promise.
Eu não vejo isso:
`` ``
teste ('assíncrono', (concluído) => {
function foo () {
retornar Promise.resolve (1);
}
foo (). então (valor => {
esperar (valor) .toEqual (2); // Nunca relatado; apenas o tempo limite.
feito();
});
});
`` ``
Não é óbvio que o código de teste deve capturar exceções para chamadas de expect
(ou seja, parte da própria estrutura de teste). Isso parece muito complicado?
Portanto, só para ficar claro, devo encerrar TODOS os testes que envolvem quaisquer funções testadas que retornem promessas com um bloco catch - para capturar expect
chamadas, que caso contrário: a) tempo limite; b) não relatar o erro.
A menos que eu esteja cometendo um erro diferente:
uma). Talvez documente isso (https://facebook.github.io/jest/docs/asynchronous.html#content)?
b). Por que não registrar o erro? e / ou tem a opção de sair?
Movendo para https://github.com/facebook/jest/issues/3576
Eu tenho o mesmo problema com console.log.
Estava funcionando bem na v19, e pude ver a saída no console.
Após a atualização para v20.0.3, a saída desapareceu.
Tentei adicionar --runInBand
ou --verbose
, mas não adiantou.
Atualize para a versão mais recente do nodejs, por favor. É um problema conhecido no nó ~ 7.3.
@thymikee Então, eles vão consertar esse problema? Eu tentei de tudo sob o sol. Ainda não há registros do console. Estou usando o pré-processador fornecido por datilografado e por jest. Eu estava usando ts-jest e seu pré-processador funcionou. É possível que tenha algo a ver com o pré-processador?
@cpojer @lsentkiewicz Devemos abrir um novo exemplar, visto que é um novo exemplar em uma nova versão?
Como @cpojer mencionou, usar a versão mais recente do node corrige o problema.
@marcusjpressedan
Funciona para mim na v7.10.0
Ainda estou vendo a saída do console ser engolida ao usar jest --bail
.
@cpojer não funciona na v8.0.0
Não funciona no nó 8.0.0
Eu sinto que este é um bug ruim se você tiver que estar em uma determinada versão para que funcione. E se seu sistema estiver rodando em 6.0 e não funcionar em 7.0 por causa de alguma mudança no nodejs. O gracejo não deveria funcionar pelo menos em versões modernas do Node? suporte de pelo menos 5 anos? @cpojer @taion
Este é um bug apenas no nó 7.3. Eles mesclaram uma alteração ruim e a reverteram para 7,4 ou 7,5.
As pessoas estão me dizendo que isso não funciona no nó 8, mas temos um teste para esse comportamento e ele está passando. Se as pessoas quiserem criar uma reprodução adequada com Jest 20 e nó 8, crie um problema para isso.
@cpojer Não estou vendo nenhuma saída console.log com esta configuração (macOS):
$ node --version
v7.4.0
package.json
:
{
"dependencies": {
"@types/jest": "19.2.4",
"jest": "20.0.4",
"ts-jest": "20.0.6",
"typescript": "2.3.4"
}
}
__tests__/jestconfig.json
:
{
"rootDir": "../",
"globals": {
"__TS_CONFIG__": {}
},
"moduleFileExtensions": [
"ts",
"tsx",
"js",
"jsx",
"json"
],
"transform": {
"\\.(ts|tsx)$": "<rootDir>/node_modules/ts-jest/preprocessor.js"
},
"testRegex": "__tests__/.*test_.*\\.(ts|tsx|js)$"
__tests__/test_foo.ts
:
import {} from 'jest';
console.log('CONSOLE before test');
test('fail', () => {
console.log('CONSOLE inside test');
expect(true).toEqual(false);
console.log('CONSOLE end of test');
})
__tests__/test_bar.js
:
console.log('BAR CONSOLE before test');
test('fail', () => {
console.log('BAR CONSOLE inside test');
expect(true).toEqual(false);
console.log('BAR CONSOLE end of test');
})
$ jest -c __tests__/jestconfig.json
FAIL __tests__/test_foo.ts
● fail
expect(received).toEqual(expected)
Expected value to equal:
false
Received:
true
at Object.<anonymous> (__tests__/test_foo.ts:6:16)
at Promise.resolve.then.el (node_modules/p-map/index.js:42:16)
FAIL __tests__/test_bar.js
● fail
expect(received).toEqual(expected)
Expected value to equal:
false
Received:
true
at Object.<anonymous>.test (__tests__/test_bar.js:4:16)
at Promise.resolve.then.el (node_modules/p-map/index.js:42:16)
Test Suites: 2 failed, 2 total
Tests: 2 failed, 2 total
Snapshots: 0 total
Time: 1.379s
Ran all test suites.
Teste JS único:
$ jest -c __tests__/jestconfig.json __tests__/test_bar.js
FAIL __tests__/test_bar.js
● fail
expect(received).toEqual(expected)
Expected value to equal:
false
Received:
true
at Object.<anonymous>.test (__tests__/test_bar.js:4:16)
at Promise.resolve.then.el (node_modules/p-map/index.js:42:16)
✕ fail (7ms)
Test Suites: 1 failed, 1 total
Tests: 1 failed, 1 total
Snapshots: 0 total
Time: 0.596s, estimated 1s
Ran all test suites matching "__tests__/test_bar.js".
Teste de TS único:
$ jest -c __tests__/jestconfig.json __tests__/test_foo.ts
FAIL __tests__/test_foo.ts
● fail
expect(received).toEqual(expected)
Expected value to equal:
false
Received:
true
at Object.<anonymous> (__tests__/test_foo.ts:6:16)
at Promise.resolve.then.el (node_modules/p-map/index.js:42:16)
✕ fail (116ms)
Test Suites: 1 failed, 1 total
Tests: 1 failed, 1 total
Snapshots: 0 total
Time: 1.27s
Ran all test suites matching "__tests__/test_foo.ts".
Tendo o mesmo problema com o nó v8.1.2. Eu também tentei o node v7.10.0 e também não funcionou
Trabalhando em um projeto React, tentei Jest porque com Jasmine é uma missão total testar chamadas HTTP com whatwg-fetch
, execução Node.js e transpilação Babel. Mas quando eu vi que no momento com o Jest você não pode imprimir no console, foi um no-no para usar este framework. Problemas com Node.js 7.10 e Jest 20.0.4.
Finalmente, consegui definir todo o ambiente de teste com a execução de Jasmine e Node.js, declarando xmlhttprequest
no escopo global e usando nock
como o servidor falso.
Os bugs podem ser muito difíceis de detectar e corrigir. Mas este é um P0 relatado há 6 meses que impedirá qualquer pessoa de considerar Jest seriamente como a estrutura de teste para qualquer projeto React.
Eu estava tendo o mesmo problema que nas capturas de tela de jest --verbose
. O que me ajudou: ao usar jest --verbose --runInBand
funcionou corretamente (primeiro resultado do teste, depois tudo console.log).
@cpojer @thymikee , por favor, reabra este problema para que ele chame atenção?
@iffy , você pode criar um problema separado com o seu repro? Vou tentar fazer a triagem e ver o que há de errado.
BTW, nada abaixo do failing expect será pago, porque expect throws.
@thymikee pronto (embora eu já tenha mudado para mocha - então não se preocupe com a triagem)
Eu também tive esse problema e, mesmo depois de ler todo este tópico e tentar de tudo, não consigo resolver o problema. Meu teste é muito simples, porque acabei de implementar jest
no meu aplicativo, e mesmo assim console.log
não aparece.
Então tentei usar winston
para registrar em um arquivo de saída e funcionou. Então tentei usar winston
para logar no console e, adivinha, funcionou!
Então, eu sugiro que vocês façam o mesmo. Verifique meu arquivo logger.js
:
'use strict';
const winston = require('winston');
const customColors = {
trace: 'white',
debug: 'blue',
info: 'green',
warn: 'yellow',
crit: 'red',
error: 'red'
};
let config = {
colors: customColors,
levels: {
trace: 0,
debug: 1,
info: 2,
warn: 3,
crit: 4,
error: 5
},
transports: [
]
};
config.transports.push(
new(winston.transports.Console)({
name: 'consoleLogger',
level: 'error',
colorize: true,
timestamp: true
})
);
const logger = new (winston.Logger)(config);
winston.addColors(customColors);
module.exports = logger;
Nos arquivos de teste, use apenas:
let log = require('./logger.js');
log.debug('some log here!');
O Winston funciona porque usa process.stdout.write
que contorna esse bug no Jest. Acabei fazendo meu próprio console.log usando o módulo util
do nó.
@eranimo @Daymannovaes, olhe para o bug # 3853
Esse comentário diz que funciona no 8.1.2, mas tentei fazer isso e não consegui fazer funcionar. Já mudei para o mocha porque esse era um bug muito ruim.
Este bug será corrigido na próxima versão? Além disso, onde posso encontrar quando isso é?
Não consigo atualizar para a versão mais recente do nó (não é uma opção), então isso não é uma solução. Eu poderia fazer meu próprio logger util com o qual posso mexer. Estou pensando em converter para mocha, mas isso depende de como meu experimento logger util vai.
Corrija o mais rápido possível, os logs do console são extremamente úteis para escrever meus testes.
Fiz o downgrade temporariamente para 19.0.2 e está funcionando.
Eu tive o mesmo problema e apenas testei com a versão mais recente do nó. Funciona agora. : 100:
Também está funcionando depois de passar do Node.js v7.10 para v8.1.
corrigido para mim ao atualizar o nó de 7.4.0
-> 8.2.1
Conseguir isso no nó v8.4.0 e Jest 21.0.0-beta.1.
Ao executar apenas um único caso de teste com test.only
, a saída console.log não aparece.
Mas se eu remover --testPathPattern file
e executar todos os testes, o resultado aparecerá.
Além disso, se eu adicionar await Promise.delay(100)
como última etapa do teste, a saída será exibida.
desculpe por este comentário, mas é uma maneira de obter Jest para console.log em tempo real, em vez de depois que um teste foi aprovado ou falhou. meu teste usa um loop while Eu estava tentando obter valores registrados enquanto o loop estava em execução?
@nharrisanalyst usa --verbose
flag
obrigado pela resposta, mas eu uso este sinalizador e apenas console.log () depois que um teste foi aprovado ou falhou. portanto, se meu loop while travar, não posso depurá-lo com console.log durante o teste, porque o teste não passa ou falha, ele apenas fica travado em um loop.
Jest parece comer qualquer console que eu faço em um setupFiles
, setupTestFrameworkScriptFile
ou beforeAll
, tornando impossível escrever scripts de configuração de teste que pedem entrada do usuário e comando de validação sinalizadores de linha. Acontece com ou sem "verbose": true
Compartilhando minhas observações em console.log () não aparecendo ao executar testes com Jest.
O pré-requisito para isso é executar Jest com a bandeira --verbose
.
Se você estiver executando testes com vários arquivos de teste , a saída de console.log () não será visível (na maioria das vezes).
Se Jest estiver executando testes de apenas um arquivo de teste , console.log () funcionará conforme o esperado.
Você pode contornar esse problema:
--maxWorkers=1
. De alguma forma, isso funciona bem para mim. Meu palpite (*) é ... O Jest é executado no mesmo processo e não há necessidade de buffer stdout de cada processo para canalizá-los de volta para o processo principal.Se meu palpite (*) é um comportamento esperado, sugiro atualizar os documentos para indicá-lo claramente para evitar que os desenvolvedores percam tempo tentando descobrir "por que meu console.log () não mostra ... às vezes".
OK, então isso ainda é um problema para algumas pessoas, incluindo eu hoje. Eu imagino que vai continuar a ser uma coisa.
Dos meus testes, Jest sai do processo antes de enviar os logs, o que significa que parece que os logs estão sendo engolidos.
Para mim, defino verbose: true
e bail: false
na minha configuração de brincadeira. O Jest continuará até que todos os testes sejam executados e exibirá todos os erros e logs. Isso é favorável. Também executei --runInBand
, que faz o mesmo que definir --maxWorkers=1
.
A maior ajuda foi bail: false
porque permitiu que todos os testes fossem executados até o final. Ele ainda saiu com o código 1
mas posso ver todos os logs novamente.
Executando Jest v19.0.2 com node v8.1.4.
Executar --verbose --testPathPattern=<path/to/file>
levou à impressão dos logs. Caso contrário, é engolido.
Alguém pode fornecer uma pequena reprodução que falhe no jest 21.2.0 e nos nós atuais (então 4.8.4, 6.11.4 ou 8.7.0)?
Não há necessidade de configurar verbose
ou configurações de jest adicionais e o problema simplesmente desaparece quando eu atualizo minha versão de nó de 7.4.0
para 8.0.0
. Essas são minhas observações.
Usando [email protected]
Isso é TÃO frustrante! Eu tenho as versões mais recentes de tudo e ainda assim Jest corta a saída do console.log em lugares aparentemente aleatórios. Isso torna muito difícil depurar testes com falha.
Acabei de encontrar a resposta para isso! Se você desligar o modo verbose, toda a saída do console.log aparecerá! Eu acho que quando a saída de Jest é algo prolixo, ele grava no topo de sua saída dos últimos console.logs.
Você tem algum pedaço de código reproduzindo isso de forma consistente? Pode nos ajudar a eliminar a inconsistência subjacente que está causando o problema.
Usei expect(<value>).toEqual("someImpossibleValue")
com bail: false
para contornar isso quando estava apenas tentando consertar algo quebrado. Definitivamente não é o ideal, mas rápido e sujo ...
Talvez você pudesse introduzir uma função assume () semelhante a expect (), mas não funciona.
executando v 22.0.4 no console.log .... adicione isso a um dos muitos outros motivos que eu não recomendo jest
@mvolkmann obrigado pela dica sobre o modo verboso. Se o modo não detalhado for o padrão de brincadeira, pode valer a pena considerar uma mudança. Não me parece intuitivo que console.logs que você coloca em seu código simplesmente não apareçam. É a primeira e básica coisa que se tenta quando um teste falha.
(nó v9.3.0 e jest v20.0.4 aqui)
jest ^21.2.1
e node 8.9.4
Jest ainda não joga logs de console às vezes, --verbose
option não resolve o problema para mim. Não entendo por que este problema foi encerrado.
@fega, já que ninguém forneceu uma caixa de reprodução, podemos puxar e testar.
$ jest --verbose
este comando irá mostrar todos os logs do console
@odykyi não funciona para mim. jest 22.1.0 e v8.9.4
comportamento estranho. Se eu definir verbose
como false
minhas declarações console.log serão impressas.
em [email protected] , [email protected] e usando --forceExit
, não vejo a saída de console.log
do meu código testado, a menos que eu defina explicitamente verbose
para false
ou remova a sinalização --forceExit
(que estou usando temporariamente).
em [email protected] , [email protected] , e usando --forceExit, não vejo a saída de console.log do meu código testado, a menos que eu defina explicitamente verbose como false ou remova o sinalizador --forceExit (que estou usando temporariamente).
Vendo exatamente o mesmo comportamento conforme afirmado acima. [email protected] , [email protected].
console.logging antes de done()
ser chamado, mas a saída não é mostrada com --forceExit
. Quando --forceExit
é removido, a saída console.log é mostrada no final.
Test Suites: 1 passed, 1 total
Tests: 35 skipped, 1 passed, 36 total
Snapshots: 0 total
Time: 2.512s
Ran all test suites matching /test\/api.test.js/i.
console.log test/api.test.js:247
bar
Portanto, não é a solução óbvia aqui para, antes de forçar a saída, liberar qualquer buffer de saída que o jest tenha internamente?
Temos um caso de teste para ele: https://github.com/facebook/jest/blob/497be7627ef851c947da830d4a8e21046f847a78/integration-tests/__tests__/console_log_output_when_run_in_band.test.js#L24 Ele está com defeito de alguma forma?
Alguém pode configurar um repo de reprodução que possamos dar uma olhada?
Adição rápida: jest --no-cache
também parece significar que console.logs não aparecem.
Com o Node 9.7.1, e jest 22.4.2 com babel 7 usando verbose parece funcionar bem para exibir logs de console de dentro de testes:
package.json
"dependencies": {
...
},
"jest": {
"verbose": true
}
Já faz algum tempo que isso não exigia a intervenção do usuário, mas parece que a solução tem sido consistente.
Esse problema também tem nos incomodado há algum tempo, primeiro com a saída sendo truncada aleatoriamente, agora a saída totalmente ignorada. Para reproduzir, clone o branch dev / dexie-search-index deste repo:
[email protected] : WorldBrain / Memex.git
Adicione esta linha em algum lugar em insertTestData () em src / search / index.test.ts:
console.log('!?!?!?!!?!?!!?'); expect(1).toBe(2)
Testado com Node.js versões 6.11 e 8.10. Resolva isso o mais rápido possível, pois torna a codificação muito mais lenta :(
@frankred thanks. Defini verbose: "false"
e funciona.
Tropecei neste problema https://github.com/evanw/node-source-map-support/issues/207 ontem e parecia terrivelmente semelhante a este problema aqui.
Isso é problemático porque as gravações em process.stdout no Node.js às vezes são assíncronas e podem ocorrer em vários tiques do loop de eventos do Node.js. Chamar process.exit (), no entanto, força o processo a sair antes que essas gravações adicionais em stdout possam ser realizadas.
https://nodejs.org/api/process.html#process_process_exit_code
Não verifiquei o código, mas se process.exit()
estiver sendo usado com --forceExit
, isso explicaria por que a saída de log está perdida.
Acabei de adicionar uma solução que funcionou para mim neste problema relacionado: https://github.com/facebook/jest/issues/3853#issuecomment -375183943
@ledbit Isso não funcionou para mim. Uau, um problema que já dura um ano e meio e ainda não tem solução.
Isso é verdade, mas ainda não há muito para os desenvolvedores continuarem.
Encontrei esse problema mais comumente em uma chamada assíncrona aninhada em um exemplo assíncrono. Não tenho certeza do caso com mais ninguém, mas mostrar seu uso de console.log certamente seria útil para resolver isso.
Certamente está acontecendo para mim. O que você precisa de mim para que possa consertar?
Em 22 de março de 2018, às 8:32 AM, Dennis Brown [email protected] escreveu:
Isso é verdade, mas ainda não há muito para os desenvolvedores continuarem.
Encontrei esse problema mais comumente em uma chamada assíncrona aninhada em um exemplo assíncrono. Não tenho certeza do caso com mais ninguém, mas mostrar seu uso de console.log certamente seria útil para resolver isso.
-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/facebook/jest/issues/2441#issuecomment-375349444 ou desative o tópico https://github.com/notifications/unsubscribe-auth/ADrayIO4NBB2dZM1XL8ZQO32vW9SUnuZ4Yks5VtO32W9SUnuZ4Yks5VtGUQ .
Melhor ainda, vá em frente! Aqui está meu repo. https://github.com/RALifeCoach/handandfootserver.git
Execute jest a partir do npm ou execute a partir da linha de comando. Você verá que existem muitos console.logs, mas a maioria está coberta.
Pronto - a equipe de desenvolvimento tem tudo de que precisa. Corrija este problema.
Em 22 de março de 2018, às 8h36, Christopher Oliphant [email protected] escreveu:
Certamente está acontecendo para mim. O que você precisa de mim para que possa consertar?
Em 22 de março de 2018, às 8:32 AM, Dennis Brown < [email protected] [email protected] > escreveu:
Isso é verdade, mas ainda não há muito para os desenvolvedores continuarem.
Encontrei esse problema mais comumente em uma chamada assíncrona aninhada em um exemplo assíncrono. Não tenho certeza do caso com mais ninguém, mas mostrar seu uso de console.log certamente seria útil para resolver isso.
-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/facebook/jest/issues/2441#issuecomment-375349444 ou desative o tópico https://github.com/notifications/unsubscribe-auth/ADrayIO4NBB2dZM1XL8ZQO32vW9SUnuZ4Yks5VtO32W9SUnuZ4Yks5VtGUQ .
@RALifeCoach olhando para o seu repo agora, há um pouco de registro nele. Importa-se de apontar qual registro em particular você está perdendo?
Executá-lo. Você verá alguma saída, mas muito será sobrescrito.
No sábado, 14 de abril de 2018, 03h10 Simen Bekkhus [email protected]
escreveu:
@RALifeCoach https://github.com/RALifeCoach olhando para o seu repo agora,
há bastante registro lá. Lembre-se de apontar qual login
particular você está faltando?-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/facebook/jest/issues/2441#issuecomment-381318608 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/ADrayHQCc8C0NmMmrtE7mEo2jN999CChks5tocsKgaJpZM4LVbUv
.
Não tenho certeza do que você entende por sobrescrito. Algo é enviado para o console então limpo?
Se seis linhas forem escritas usando console.log, as 6 aparecerão brevemente e, em seguida,
o resumo do teste se sobrepõe a algumas das 6 linhas.
No sábado, 14 de abril de 2018, 8h58, Simen Bekkhus [email protected]
escreveu:
Não tenho certeza do que você entende por sobrescrito. É algo que sai para o
console então limpo?-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/facebook/jest/issues/2441#issuecomment-381339074 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/ADrayF0P5SqpHjaAAYcPaIAF7ubSMVRTks5tohyIgaJpZM4LVbUv
.
Também estou experimentando o que @RALifeCoach está descrevendo. Verei minha saída de log piscar na tela enquanto os testes são iniciados e, quando rolar para cima, essa saída não está mais lá.
Parece que isso ainda é um problema, mesmo no nó 8.11.1. Talvez devêssemos registrar um novo bug e consultar aqui?
Ainda tenho o mesmo problema no nó v8.9.0.
Posso confirmar o comentário de @RALifeCoach sobre a saída do log ser "sobrescrita" - finalmente consegui que os logs apareçam marcando cada um com uma string específica de caracteres (por exemplo, @@@
) e executando:
yarn test --verbose | grep '@@@'
É um hack terrível (você perde todas as cores do console, mas ainda vê falhas no teste e um resumo final do teste), mas é a única coisa que funcionou até agora. Eu tentei de tudo nos comentários acima. Observe que --verbose
arg é necessário para esta solução (e está sendo implicitamente combinado com --watch
por meio de react-scripts
).
[Usando react-scripts
bifurcado para usar o Jest v23.0.0 mais recente, nó v8.11.2]
Configurar "verbose": true
no package.json ajuda. Os logs aparecem na parte inferior da saída.
Cara, para um assunto encerrado. Ainda vejo pessoas reclamando disso desde que foi criado há 2 anos.
Acho que há algum código no Jest que brinca conosco e "sequestra" console.log (),
tornando-o um ambiente autônomo, algo como ...
console.log = function(){ /* do nothing */}
A solução para redefinir o console.log é, ironicamente - consulte https://stackoverflow.com/questions/7089443/restoring-console-log
- para excluir console.log
delete console.log
console.log("Can you hear me now, Jesters...?");
... e de repente - Voila! - como uma Fênix das chamas - console.log()
funciona novamente em Jest ...!
Jest até imprime "console.log (informações de localização)" antes de registrar sua mensagem ...
>
console.log __tests __ \ libarray-helpers.test.js: 35
Você pode me ouvir agora, Jesters ...?
Além disso, tenho usado "logatim" isomórfico recentemente https://www.npmjs.com/package/logatim em vez de console.log (), e
parece imune às tentativas de sequestro de Jest ... (talvez ele redefina console.log ...)
Você pode até "sequestrar" o console.log preventivamente por logatim
para registrar uma mensagem de nível "info" em verde ...
// const logatim = require('logatim') // ES5
import logatim from 'logatim' // ES6
/* ... */
console.log = function(...args){ logatim.green.info("[INFO]",...args) } // ES6
(Por favor, não interprete minha jocosidade como belicosidade ... onde está a alegria em nomear um bom produto Jest se você não pode brincar sobre isso brincando um pouco ...)
Antes de espalhar o ódio, @ yanshuf0 , considere as ferramentas gratuitas e abertas das quais você está claramente se beneficiando. Você escolheu usar o Jest. Se você não gostar, pode optar por sair (ou consertar você mesmo, a equipe é amigável e aberta a RPs).
Eu estava tendo esse problema de "substituição" (Windows 10, terminal VS Code, projeto node.js) e então, enquanto eu mexia nele, o bug parou de acontecer. Achei que tinha parado de acontecer porque parei de usar --watch
ou porque adicionei uma opção "verbose": false
, mas reverter essas alterações não fez o bug voltar.
Tenho que perguntar, porém, Jest intencionalmente não associa a saída do log com o teste que a produziu? Por algum tempo, toda a saída do console ficou abaixo de todos os resultados do teste, mas agora é mostrada acima de todos os resultados do teste. Tão aleatório.
--watchAll sinalizador bloqueou. agora funciona para mim
Depois de usar o jest por meses, isso aconteceu comigo também do nada com o nó 8.9. Em um minuto, console.log estava exibindo bem, no minuto seguinte ele simplesmente parou de funcionar. Acabei neste tópico e tentei algumas coisas. Não usar --watch
resolveu o problema, mas tive que executar novamente meu comando de teste todas as vezes. Usar --watch --verbose false
corrigiu o problema e executou meus testes automaticamente.
Encontrando o mesmo problema aqui, obrigado pela correção temporária @bkempner
Pode confirmar que este é um problema em 22.4.4 e 23.4.1 (atual até este comentário). As sinalizações que estou usando são:
$ jest --forceExit --runInBand --bail --ci --json --outputFile=/tmp/jest_results.json
Outro problema no mesmo tópico sugeriu adicionar a opção --json
, que funcionou por um tempo ... Talvez alguma dependência tenha mudado desde então, mas a saída STDOUT e STDERR é sempre suprimida. O mais próximo que cheguei de qualquer coisa que funcionou foi usar --watch
; às vezes, alguma saída ficava presa no final sem ser sobrescrita.
Descobri que --silent
é verdadeiro por padrão, definir como falso irá gerar o console.log: jest --silent=false
Parece uma tonelada de relatos sobre isso, algo claramente ainda está quebrado. Isso foi encerrado como uma cópia do # 2166 que agora está encerrado, mas ainda persiste.
@thymikee Podemos reabrir este problema?
Estou reabrindo isso, pois o problema está parcialmente de volta e precisamos corrigi-lo.
Na v23, o problema aparece no modo de observação, já que mudamos a forma como ele funciona nos bastidores para quase sempre executar testes em paralelo, para que o TTY não seja bloqueado e seja possível cancelar testes de longa duração facilmente: https: // github. com / facebook / jest / pull / 6647.
O único caso em que não estamos gerando workers no modo de observação é quando temos exatamente 1 teste para executar e é relativamente rápido (executa abaixo de 1s) - neste caso, ainda devemos ver console.log
s aparecendo como sempre.
No meu caso, executar todos os testes no modo relógio faz login corretamente. Se eu usar o modo padrão para filtrar apenas uma classe de teste, o registro será truncado
De acordo com o comentário de @davidgilbertson (https://github.com/facebook/jest/issues/2441#issuecomment-286248619) removendo verbose: true
em meu package.json e removendo --verbose
de meu sinalizadores de linha de comando me permitem ver os logs do console que de outra forma estavam ocultos. Isso é muito confuso.
Eu tenho verbose: true
em meu package.json e estou descobrindo que console.log
declarações às vezes estão lá e às vezes não (se eu tiver como 10 em todos eles parecem aparecer, mas não para apenas um) - Estou pensando que talvez seja um problema assíncrono
Também tenho esse problema ocasionalmente, habilito runInBand
(https://jestjs.io/docs/en/cli.html#runinband) e isso corrige o problema.
@ndelangen que é curioso - eu me pergunto se talvez seja um problema assíncrono então. Achei que Jest colecionou todos os console.logs e os imprimiu no final, não?
O problema é recorrente agora, embora eu não esteja usando verbose
.
--runInBand
não corrige isso para mim. A única solução alternativa confiável até agora é apenas registrar algo várias vezes para que parte da saída não seja sobrescrita por jest.
Fiz algumas análises, adicionei alguns comentários e consegui criar um patch parcial aqui:
https://github.com/facebook/jest/issues/3853#issuecomment -413622844
editar:
repo contendo código para reproduzir facilmente disponível aqui: https://github.com/spion/jest-logging-repro
análise de saída aqui: https://gist.github.com/spion/bbb34c5abc1230a37ad5f4f01336b8df
O patch é parcial porque
@philraj mesmo problema para mim .. eu tenho que registrar várias vezes para ver de forma confiável a mensagem de registro pretendida
como isso não é uma grande preocupação e não é resolvido o mais rápido possível? como é que essa questão está aberta desde 2016 ??
Atualização: com este patch, tenho apenas 8 testes com falha:
diff --git a/packages/jest-runner/src/index.js b/packages/jest-runner/src/index.js
index 2f4dd724..618a8cbf 100644
--- a/packages/jest-runner/src/index.js
+++ b/packages/jest-runner/src/index.js
@@ -97,11 +97,14 @@ class TestRunner {
// $FlowFixMe: class object is augmented with worker when instantiating.
const worker: WorkerInterface = new Worker(TEST_WORKER_PATH, {
exposedMethods: ['worker'],
- forkOptions: {stdio: 'inherit'},
+ forkOptions: {stdio: 'pipe'},
maxRetries: 3,
numWorkers: this._globalConfig.maxWorkers,
});
+ worker.getStdout().pipe(process.stdout);
+ worker.getStderr().pipe(process.stderr);
+
const mutex = throat(this._globalConfig.maxWorkers);
// Send test suites to workers continuously instead of all at once to track
diff --git a/packages/jest-worker/src/worker.js b/packages/jest-worker/src/worker.js
index 5eee64af..17d76d36 100644
--- a/packages/jest-worker/src/worker.js
+++ b/packages/jest-worker/src/worker.js
@@ -87,6 +87,13 @@ export default class {
}
_initialize() {
+ const forceColor =
+ 'FORCE_COLOR' in process.env
+ ? process.env['FORCE_COLOR']
+ : // $FlowFixMe: Does not know about isTTY
+ process.stdout.isTTY
+ ? '1'
+ : '0';
const child = childProcess.fork(
require.resolve('./child'),
// $FlowFixMe: Flow does not work well with Object.assign.
@@ -94,6 +101,7 @@ export default class {
{
cwd: process.cwd(),
env: Object.assign({}, process.env, {
+ FORCE_COLOR: forceColor,
JEST_WORKER_ID: this._options.workerId,
}),
// Suppress --debug / --inspect flags while preserving others (like --harmony).
Eles são principalmente sobre não esperar FORCE_COLORS em process.env, hg scm e packages/jest-runner/src/__tests__/test_runner.test.js
não simular completamente os fluxos (portanto, não há métodos de pipe neles.
Nesse ritmo, poderei enviar um PR que corrige na próxima semana ... desde que eu encontre uma correção para a saída do log que aparece após a conclusão de todo o relatório.
Como @bkempner disse, usar --watch --verbose false
corrige o problema.
A saída do console em --watch
sendo substituída por simplesmente mover o cursor é consistente com o que estou vendo. A presença / ausência de --verbose
, --maxWorkers 1
, --runInBand
não produz sucesso.
Minha solução alternativa atual é jest --watch | cat
. Perco toda a cor e fico no topo da janela, mas recebo a saída do console.
Ou TERM=dumb jest --watch
. Perco em ficar no topo da janela, mas obtenho cores e a saída do console.
Eu tive o mesmo problema.
O que funcionou para mim foi usar console.debug
TERM=dumb
corrige para mim
FWIW, TERM = dumb corrige para mim também
desativar verbose
na configuração do jest funcionou para mim 0_o \
Adicionar --verbose false
ao script de "teste" package.json resolveu o problema para mim. Eu nunca teria encontrado isso sem este tópico.
por exemplo
"scripts": {
"test": "jest --watch --verbose false"
}
Estranho como alguns dos últimos consoles desaparecem, mas não todos, consertei com --verbose false
no meu comando watch.
Funciona bem quando você executa sem --watch
portanto, é algo sobre o sinalizador de relógio que o faz.
O que é tão irônico é que é mais prolixo quando o console.log funciona!
Comecei a perceber esse problema com o verbose em Jest 23.6, voltei para 23.5 e ainda estou vendo. Se eu executar --clearCache
isso será corrigido por um tempo até que falhe novamente. Não estou certo de qual é o gatilho, como muitas falhas de log ou algo parecido. Quando isso acontece, parece que Jest corrompe o cache. Estou tentando --verbose false
e vejo se isso impede que continue.
Obrigado @jamespolanco. Usar a opção --clearCache
resolveu o problema para mim (por enquanto). Vou executar meus testes usando a opção --no-cache
e ver se isso evita que o problema se repita no futuro.
EDIT: Eu deveria ter mencionado que meu problema era que apenas algumas das minhas console.log
mensagens foram impressas. Usei 5 console.log
linhas em um teste e apenas as 3 primeiras linhas foram impressas. Usar --clearCache
corrigiu esse problema para mim. Talvez haja um problema diferente em que nenhum console.log
s aparece?
Eu tambem tenho esse problema. Tentei usar console.log, console.debug e console.error. Também tentei usar o sinalizador --no-cache. Em todos os casos, minha instrução de console está sendo completamente ignorada.
Também estou tendo o mesmo problema.
Também estou experimentando isso quando uso verboso ou quando estou no modo de relógio
Acredite ou não, às vezes eu registro lançando um erro. Também fazer node --inspect node_modules/.bin/jest --runInBand mypath/to/my.test.js
mostra as saídas de console.log
reais no meu caso.
Node v9.11.1
Jest: v23.6.0
Configuração do Jest em package.json
:
"jest": {
"preset": "react-native",
"verbose": true,
"testEnvironment": "node",
"haste": {
"defaultPlatform": "android",
"platforms": [
"android",
"ios",
"native"
],
"providesModuleNodeModules": [
"react-native"
]
},
"setupFiles": ["<rootDir>/__tests__/setup"]
},
Confirmo que o problema é com verbosidade. O problema é que o cálculo da contagem de linha é confuso quando detalhado está ativado.
Se alguém puder me indicar o lugar onde imprime a mensagem, posso tentar.
Você pode mitigar a emissão usando jest-watch-toggle-config
por enquanto.
Configure assim:
module.exports = {
"watchPlugins": [
["jest-watch-toggle-config", { "setting": "verbose" }]
]
}
Ao executar o teste, pressione v
para ativar o verbose e v
novamente para desativá- lo.
Depois disso, enquanto você mantiver o verbose desativado, poderá ver todos os logs.
--verbose=false
corrigiu o problema para mim ao testar a enzima superficial . Os console.logs estavam, entretanto, funcionando sem a correção para a montagem da enzima .
Isso sugere uma diferença entre como os erros são registrados pelo renderizador de teste do react e como eles são registrados pelo renderizador embutido do react (uma vez que a enzima não interfere nas funções do console)
Para sua informação, este PR corrige o problema para mim - https://github.com/facebook/jest/pull/6871
Ainda não está pronto, pode ser necessário alterar a abordagem - mas exibe todos os dados registrados no modo detalhado.
Ainda não atualizei (executando jest 22.4.2), mas usando o modo de observação, meus logs não apareceriam. Executando com --runInBand
corrigiu no modo de relógio.
"test": "jest --watch --runInBand",
"test:once": "jest",
Eu também não atualizei (Jest 23.6.0), e executando com "jest --watch --verbose = false" corrige para mim também.
Adoraria que as pessoas tivessem problemas para testar o PR mencionado acima. Está disponível em jest@beta
( 24.0.0-alpha.9
agora)
Então yarn add jest @ beta?
ons. 19. des. 2018 kl. 16:46 skrev Simen Bekkhus [email protected] :
Adoraria que as pessoas tivessem problemas para testar o PR mencionado acima. Isso é
disponível em jest @ beta (24.0.0-alpha.9 agora)-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/facebook/jest/issues/2441#issuecomment-448641697 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAM5P7ijQjSbWB0-zzDCfC9Uggyk5RGoks5u6l9EgaJpZM4LVbUv
.>
Tarjei Huse
Mobil: 920 63 413
@tarjei , sim:
yarn add --dev jest<strong i="7">@beta</strong>
Está funcionando para mim. 🎉
Isso é realmente bobo, mas apenas no caso de ajudar alguém, estou trabalhando em um novo projeto (para mim) - jest estava sendo executado com a opção --silent
que desativa a saída. Removi isso e estou vendo os logs agora 🤦♂️
Observe que quando verbose está habilitado (eu alterno usando jest-watch-toggle-config
), parte do log do console está sendo bloqueado no beta.
--verbose = false
Isso funcionou para mim.
Percebi que alguns console.log()
estavam trabalhando enquanto outros não em meus testes (node v8, [email protected])
const something = () => new Promise(resolve => {
console.log('NOT logged for some reason!')
setTimeout(resolve, 100);
});
describe('Something', () => {
it('logging works in non-async test', function () {
console.log('logged 1')
console.log('logged 2')
expect(true).toBe(true);
});
it('console log does not work well in async test', async () => {
console.log('logged 3')
await something();
console.log('NOT logged!')
expect(true).toBe(true);
});
});
/* Output:
> logged 1
> logged 2
> logged 3
*/
Há algo muito estranho acontecendo, com async
testes onde o primeiro console.log
no teste assíncrono não está sendo logado, também aquele após o await
não está logado.
Adicione mais console.log
naquele teste async
e você começará a notar um comportamento ainda mais estranho, como alguns dos logs após o await
funcionar de repente 🤷♀️ 🤷♂️
Então, o que @philwhln escreveu acima, dois anos atrás
Como não posso isolar isso em um teste simples, acho que tem a ver com a execução de um teste assíncrono mais complexo.
Parece haver alguma verdade nisso.
--verbose = false
Também funcionou para mim neste caso.
@DanweDE você pode verificar se o alfa mais recente yarn add jest<strong i="6">@beta</strong> --dev
corrige o problema para você, mesmo com verbose definido como true
?
Adicionar --verbose false
corrigiu o problema. Isso parece um pouco não intuitivo :)
Isso está consertado? Ainda não estou vendo console.logs em "jest": "23.6.0"
@iDVB Se você ler o tópico alguns comentários acima, verá que há uma versão beta que supostamente corrige o problema. Tente isso e relate se isso resolve seu problema para ajudar @spion
Além disso, todos que vêm aqui para dizer --verbose false
ou --verbose true
ou qualquer combinação de sinalizadores ou versões de Node ou Jest corrigiram seu problema, tente a versão beta e relate se ela corrige seu problema sem a sua solução alternativa.
os registros do console nas classes que estou testando aparecem
@philraj mudamos para a versão beta "24.0.0-alpha.9"
em @leaplabs e funciona perfeitamente. No sentido de que não vi nenhum log desaparecer desde que atualizamos.
Também pode confirmar, funciona em 24.0.0-alpha.9
sem qualquer argumento de linha de comando.
Sou relativamente novo no React and Jest. Não consegui obter logs consistentes usando os padrões de create-react-app. Eu ejetei e agora os logs estão funcionando bem. Não acho que ejetar mudou a versão de Jest. Talvez isso tenha alterado apenas uma das configurações de funcionamento do Jest. Isso é com 23.6.0
.
Ao usar 24.0.0-alpha.16
, não vejo nenhum log do console, a menos que adicione verbose=false
.
Também obtenho resultados bastante inconsistentes com isso em [email protected]. Se eu executar todas as alterações no modo de observação (a), poderei ver a saída do console, mas não se executar as alterações relacionadas no modo de observação (o).
--verbose=false
corrigiu isso para mim também 🎉
Estou usando 24.1.0
e funciona mesmo sem a opção detalhada. No entanto, ele não produz nenhuma instrução console.log
no arquivo de teste quando o arquivo de teste contém, por exemplo. referência à classe, que não é importada. Por exemplo
Isso é um erro de ts-jest
e não é realmente relevante aqui
Sim, mas quando esse erro ocorre, a saída do log do console não é exibida. Isso ainda é relevante para ts-jest
? Não estou muito familiarizado com o que cada biblioteca em torno de piadas é responsável.
IDK como ts-jest
funciona, mas se não executar nenhum teste em erros de tipo, isso explicaria por que eles estão faltando - o código nunca é executado
Ainda estou lutando para fazer console.log
trabalhar aqui. Ocasionalmente, obtenho registros, mas parece não haver um padrão discernível para o sucesso.
Estou usando o Jest 24.7.1
e também tentei 24.7.1
e 24.2.0-alpha.0
.
A configuração verbose=false
e verbose=true
falharam em fornecer uma correção.
Também tentei usar o nó v10.8.0
e v6.17.1
, também sem correção.
Está faltando alguma coisa aqui?
@mulholio, você tem 100% de certeza de que está executando o jest instalado localmente? Eu relatei problemas no passado que só aconteceram porque eu tinha uma versão global antiga de um pacote que estava sendo executado em vez da instalada localmente.
Sim, nenhuma versão global do Jest instalada
posso confirmar que não foi resolvido. às vezes o console.log funciona e às vezes não, como me confundiu.
meu ambiente da seguinte forma:
jest 23.6.0
nó v8.13.0
e meu jest.config.js
const path = require('path');
module.exports = {
moduleNameMapper: {
"\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$": "<rootDir>/__mocks__/fileMock.js",
"\\.(less|css|scss)$": "<rootDir>/__mocks__/cssMock.js",
"^@\/(.*)$": "<rootDir>/src/client/$1",
},
bail: true,
setupTestFrameworkScriptFile: "<rootDir>/setupTests.js",
collectCoverageFrom: [
"src/client/**/*.{js,jsx}",
],
verbose: true,
coverageReporters: ["text", "text-summary", "lcov", "json"],
coveragePathIgnorePatterns: ["src/client/index.js"],
}
sim, após remover verbose: true , parece bom
Também vejo esse bug. Podemos abrir esse problema novamente?
Para sua informação: Se eu usar fit
para executar um único teste, meu console.log
s não produziu nada. Quando executei todo o conjunto de testes, os console.log
s funcionaram perfeitamente.
Encontrando o mesmo problema, alguns logs do console são "consumidos". Para aqueles que têm esse problema, você pode verificar, mas clonar vários logs de console?
console.log('ok');
console.log('ok');
console.log('eaten up');
Parece que o buffer para a instrução [PASS] está sendo escrito nas últimas 2 linhas de log do console (posso ver parte do número da linha de log do console no final da instrução Pass)
+1000
parece muito bobo, mas certifique-se de yarn build
antes dos testes!
Ainda sem saída com --verbose=true
ou --verbose=false
ao usar [email protected]
- não sei por que ainda é um problema 3 anos depois de ter sido originalmente registrado.
Você já tentou usar o sinalizador jest
--runInBand
para ver se isso resolve o problema executando testes em série? Alguém mencionou isso para mim, mas não teve oportunidade de testá-lo.
Obrigado, funciona! Mas por que não defini-lo como padrão para ter a saída de console.log ..
Isso ainda é um problema para mim, [email protected]
Eu encontrei uma correção, na verdade, as últimas 2 linhas no último caso de teste (em cascata) são substituídas, então, faça deste o seu último caso de teste
it('bugfix for [email protected]', () => {
console.log("[email protected] bug|last 2 lines get override. remove this once 24.8.0 gets fixed");
console.log("[email protected] bug|last 2 lines get override. remove this once 24.8.0 gets fixed");
});
Para aqueles que usam ts-jest
, tive que desligar o diagnóstico para ver o console.logs
jest.config.js
globals: {
'ts-jest': {
diagnostics: false,
},
},
Para aqueles que usam
ts-jest
, tive que desligar o diagnóstico para ver o console.logs
jest.config.js
globals: { 'ts-jest': { diagnostics: false, }, },
Essa opção não funcionou para nós. Também tentamos definir verbose = false
que também não ajudou.
Nosso ambiente:
Parece que o buffer para a instrução [PASS] está sendo escrito nas últimas 2 linhas de log do console (posso ver parte do número da linha de log do console no final da instrução Pass)
Este parece ser o meu caso ([email protected]). No meu sistema, a linha de saída do terminal com [PASS] parece piscar algum conteúdo antes de ser apagado.
Enfrentando esse problema também.
Não consigo fazer login com nenhuma das soluções acima, mas como solução alternativa, espero falhar com o valor e verificar o diff:
expect(thingIWantToLog).toBe({})
Também encontrei isso: parece que a saída "PASS: ..." está sobrescrevendo o stdout, então seu "último" console.log será comido.
Se --verbose=false
não funcionar, você pode adicionar um monte de novas linhas de sacrifício ( \n
) ao seu último console.log.
Você já tentou usar o sinalizador jest
--runInBand
para ver se isso resolve o problema executando testes em série? Alguém mencionou isso para mim, mas não teve oportunidade de testá-lo.
Adicionar este sinalizador ajudou a resolver o problema.
De vez em quando, também não mostrava as saídas de console.log.
Usando este comando:
npm test -- --verbose --runInBand -t "My Test Name"
Versões de nó e NPM:
node v8.16.0
npm 6.4.1
Este é o meu ambiente de trabalho:
npm install --save-dev sprintf-js
Em sua brincadeira setupTest.js
, ou onde quer que:
import {sprintf} from 'sprintf-js';
console.log = (msg, args) => {
const str = sprintf(msg, args);
process.stderr.write(str + '\n');
};
Ainda sem saída com
--verbose=true
ou--verbose=false
ao usar[email protected]
- não sei por que ainda é um problema 3 anos depois de ter sido originalmente registrado.
Este é meu jest.config.js
e funcionou para mim.
jest -v 23.6.0
& node -v 8.11.2
module.exports = {
clearMocks: true,
moduleDirectories: [
'node_modules',
],
testEnvironment: 'node',
testMatch: [
'**/__tests__/**/*.js?(x)',
'**/?(*.)+(spec|test).js?(x)',
],
verbose: false,
};
Então, em package.json
eu tenho:
"scripts": {
"test": "jest --config ./jest.config.js",
}
Em seguida, execute seu conjunto de testes específico com este comando:
yarn test -- -t 'test-suite-name-here'
--verbose=false
parece ter funcionado para mim. Obrigado!
Simplesmente esconda os logs e avisos quando você passar a opção --silent
Tente yarn jest
deve funcionar
Esse bug é tão chato ... 3 anos ...
desligar - silenciar
e para testes de ts usando a solução ts-jest @ mr-madamin funcionando para mim!
Não usando verbose
ou silent
, tentei --runInBand
, TERM=dumb
, executando todos os testes vs. arquivo de teste único, e console.log
aparece quando colocado em blocos de configuração, mas não dentro de blocos de it()
.
Quando tudo mais falhar, você ainda deve ser capaz de fazer:
require('fs').writeFileSync('./output', data);
Mas me sinto como um homem das cavernas usando uma pedra para quebrar um amendoim.
editar: "jest": "^24.9.0"
Estou usando este comando e funciona:
npm test -- --runInBand -t "My Test Name"
Você pode especificar seu Nome de teste após o sinalizador -t para executar testes individuais ou grupos de teste sob o mesmo describe () .
Não usando
verbose
ousilent
, tentei--runInBand
,TERM=dumb
, executando todos os testes vs. arquivo de teste único, econsole.log
aparece quando colocado em blocos de configuração, mas não dentro de blocos deit()
.Quando tudo mais falhar, você ainda deve ser capaz de fazer:
require('fs').writeFileSync('./output', data);
Mas me sinto como um homem das cavernas usando uma pedra para quebrar um amendoim.
editar:
"jest": "^24.9.0"
Eu estava animado para finalmente começar a usar o jest no back-end para uniformidade. Em vez disso, estou enfrentando esse problema e, a partir de agora, estou voltando para mocha / proxyquire. Nenhuma saída console.log
visível (em módulos ou casos de teste) e depois de passar várias horas nisso, nenhuma das soluções alternativas parece ajudar. Não estou interessado em nenhuma solução alternativa que envolva o registro em arquivos ...
Testado em relação ao nó 8/10 LTS com "jest": "^24.9.0",
Sim. Eu também estou no limite. Parece que é mais popular aqui encerrar o problema e recomendar hacks em vez de consertar pontos de dor óbvios por mais de 3 anos.
Olá samlevin e pavelloz,
Você já tentou esta opção?
Estou usando este comando e funciona:
npm test -- --runInBand -t "My Test Name"
Você pode especificar seu Nome de teste após o sinalizador -t para executar testes individuais ou grupos de teste sob o mesmo describe ().
Você poderia me dizer se funciona? Como venho usando há um tempo.
Aqui está uma captura de tela com um código de exemplo e saída.
NOTE que: caso você não saiba, o console.lg é impresso na parte superior de todos os outros relatórios, e não no final onde você vê o relatório de cobertura de código ou o resumo do erro.
Meu Node e versões NPM:
node v8.16.0
npm 6.4.1
Eu estava animado para finalmente começar a usar o jest no back-end para uniformidade. Em vez disso, estou enfrentando esse problema e, a partir de agora, estou voltando para mocha / proxyquire. Nenhuma saída
console.log
visível (em módulos ou casos de teste) e depois de passar várias horas nisso, nenhuma das soluções alternativas parece ajudar. Não estou interessado em nenhuma solução alternativa que envolva o registro em arquivos ...Testado em relação ao nó 8/10 LTS com
"jest": "^24.9.0",
Eu testei cada solução neste segmento.
Só para verificar se nada mudou nesse sentido:
bash-5.0$ npm -v ; node -v; cat node_modules/jest/package.json |grep version
6.12.0
v12.11.0
"version": "24.9.0",
Editar
NOTE que: caso você não saiba, o console.lg é impresso na parte superior de todos os outros relatórios, e não no final onde você vê o relatório de cobertura de código ou o resumo do erro.
Eu não estava nem verificando o final do relatório, mas foi exatamente onde meu log caiu. Então eu acho que funciona, mas não de forma consistente / da mesma forma para todos.
Obrigado pela ajuda.
A questão é o quanto isso prejudica o desempenho, mas isso fica para outro dia, o registro é mais importante.
Você está certo @pavelloz , quando você executa os testes com a opção --runInBand vai demorar mais tempo para finalizar os testes porque faz o seguinte:
--runInBand, -i Run all tests serially in the current process
(rather than creating a worker pool of child
processes that run tests). This is sometimes
useful for debugging, but such use cases are
pretty rare.
Portanto, o que faço é usar essa opção apenas quando preciso depurar um problema em um teste.
Em qualquer outro momento, apenas execute o teste normalmente.
Felicidades
componente const = raso (...)
console.log (component.debug ())
É incrível que isso ainda não tenha sido corrigido.
@ivandosreisandrade Consegui verificar a solução alternativa do sinalizador runInBand
mas, neste momento, prefiro não perder tempo adicionando a etapa extra para outros desenvolvedores e revertido para algo que se comporta como esperado fora da caixa. permanecerá inscrito para ver se alguma coisa muda a esse respeito
Eu tentei de tudo neste tópico e ainda não consigo ver a saída para console.log. --runInBand não resolve o problema para mim. Usando o node @ 12 e o mais recente jest. Depurar com web dev é difícil o suficiente, seria muito útil se eu pudesse pelo menos imprimir na tela para ver por que meu teste de unidade está falhando
@ u84six , você já tentou minha solução?
Aqui está o link para minha resposta no post.
https://github.com/facebook/jest/issues/2441#issuecomment -552368939
Felicidades
@ivandosreisandrade o que acontece é que se houver um erro no código (como fazer referência a um valor indefinido), ele não será impresso, mesmo que a chamada console.log seja anterior ao erro. Se tudo passar no teste, verei o log. Esse tipo de comportamento o torna totalmente inútil para depuração.
@ivandosreisandrade como é o seu package.json? Estou tentando seguir isto:
teste npm - --runInBand -t "Meu nome de teste"
Mas eu tenho uma configuração assim no meu package.json
" test: unit ": "jest --verbose"
Você pensaria que com o sinalizador --verbose, isso permitiria que um console.log passasse, mas ainda não consigo fazer o console.log funcionar. Tão frustrante!
@ivandosreisandrade como é o seu package.json? Estou tentando seguir isto:
teste npm - --runInBand -t "Meu nome de teste"
Mas eu tenho uma configuração assim no meu package.json
" test: unit ": "jest --verbose"
Você pensaria que com o sinalizador --verbose, isso permitiria que um console.log passasse, mas ainda não consigo fazer o console.log funcionar. Tão frustrante!
@ u84six este é meu packadge.json
"scripts": {
"test": "jest test --coverage",
...
},
...
"jest": {
"verbose": true,
"testMatch": [
"**/tests/**/*.js?(x)"
],
"moduleFileExtensions": [
"js"
],
"moduleDirectories": [
"node_modules"
]
}
Seu testMatch permite .js
ou .jx
ou .jsx
arquivos, e seu moduleFileExtensions permite apenas .js
. Parece que há algo errado.
Não é relevante para a causa: man_shrugging:
Esse é exatamente o arquivo que deve ser localizado e executado os testes.
Não tenho certeza de por que o problema foi encerrado. Então, aqui está minha versão do nó - 13.12.10, npm -6.14.4
jest -24.9.0
Aqui está um teste básico com mock-fs
importar mock de 'mock-fs';
import * as fs de 'fs';
importar bomba de 'bomba';
import * as util de 'util';
describe('Test suite for bucket functionality', () => {
beforeEach(() => {
mock({
'sample-file.txt': 'Content of the sample file',
'sample-upload.txt': ''
});
});
test('test upload', async () => {
const filePromisy = util.promisify(fs.readFile);
pump(fs.createReadStream('sample-file.txt'), fs.createWriteStream('sample-upload.txt'));
filePromisy('sample-upload.txt').then(data => {
// when I do a console.log() here I get a warning stating that before I do an expect of data , I get a warning (no longer an error) stating that -_Cannot log after tests are done._
}).catch(err => {
});
});
test('test download', () => {
});
});
Não tenho certeza de por que isso acontece. Isso ocorre por causa do loop de eventos em que o console.log é feito para ser considerado processado no nextTick () somente após a execução das especificações de teste. Peço desculpas por trazer isso à tona, mas parece entediante depurar cada caso de teste, em vez de apenas fazer um o / p no console e verificar os dados solicitados.
Porque você tem que devolver sua promessa de arquivo Promisy para que ele saiba quando seu teste for feito - seu problema não tem nada a ver com este.
Eu resolvi esse problema para fins de depuração, simplesmente colocando tudo o que eu queria fazer login em uma instrução temporária expect
. Portanto, em vez de console.log(sketchyVariable)
, use expect(sketchyVariable).toEqual(42)
.
O que funcionou para mim no Nó 8:
Em vez de usar console.log
, use o registro de depuração integrado:
const util = require('util')
const myLogger = util.debuglog('myloggername')
myLogger('foobar')
E comece a brincar com o sinalizador do depurador:
NODE_DEBUG=myloggername npm test -t "My Test Name"
Eu estava vendo os logs do console aparecerem esporadicamente ao assistir a um único teste. Às vezes, eu veria todos os logs, outras vezes nenhum e, outras vezes, veria alguns deles, mas não todos. Cada vez que o teste fosse executado, eu veria algo diferente. 😒
--verbose=false
consertou para mim. Fiquei surpreso com isso, porque não estou definindo verbose
como true
nenhum lugar. Acontece que Jest o definirá como true
automaticamente se você estiver executando um único teste . 🙃
se houver apenas um arquivo de teste sendo executado, o padrão será verdadeiro.
https://jestjs.io/docs/en/configuration#verbose -boolean
Tópico StackOverflow relacionado: https://stackoverflow.com/questions/48695717/console-log-statements-output-nothing-at-all-in-jest
jest não lida bem com o log em vários níveis. deveria
é isso. não é complicado realmente.
Meu palpite é que eles estão capturando os logs do console porque estão tentando fazer com que a saída assíncrona seja impressa em uma ordem sã ao executar os testes. O problema é que, se esse código de registro não funcionar para um usuário, em seu ambiente, eles estão praticamente bloqueados.
Eu parei de usar o jest anos atrás, porque não conseguia obter a saída do console de forma confiável ao depurar testes, não importa quais sugestões eu segui neste tópico.
A moral da história é: não mexa no console global. SEMPRE. Se você quiser fornecer um registrador que possa ser ligado ou desligado, faça isso. Vou usar se quiser. Mas o console global não deve ser interferido.
Obtenha o Outlook para iOS https://aka.ms/o0ukef
De: earonesty [email protected]
Enviado: quarta-feira, 12 de agosto de 2020 12:33:23
Para: facebook / jest [email protected]
Cc: Chris Grimes [email protected] ; Mencione a mençã[email protected]
Assunto: Re: [facebook / jest] console.log não produz resultados durante a execução de testes (# 2441)
jest não lida bem com o log em vários níveis. ele deve capturar logs e mostrá-los em caso de falha por padrão, ter a opção de não mostrar nenhum e ter a opção de mostrar todos. é isso.
-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/facebook/jest/issues/2441#issuecomment-673011577 ou cancele a inscrição https://github.com/notifications/unsubscribe-auth/AAFCNBK5MQEA6AJHEC52ZWDSALG6HANCNFSM4C2VWUXQ .
@halis , uso o Jest
Minha sensação é que a principal jogada de Jest é ficar feliz em quebrar o comportamento e a semântica esperados de vez em quando, se isso melhorar drasticamente a experiência de teste. Coisas como o autohoisting de jest.mock(...)
significam que os testes Jest não são estritamente JavaScript (ou mesmo ECMAScript) em sua semântica; da mesma forma, paralelismo significa que quaisquer métodos internos de retorno de vazio como console.log
podem e devem ser tratados como assíncronos, se puderem melhorar o desempenho.
Isso é uma coisa ruim? Claramente não necessariamente, já que Jest é um enorme sucesso. Mas acho que Jest tem a capacidade de surpreender você de vez em quando. Tenho certeza de que 90% dos usuários do Jest não têm ideia de que seu código foi transformado em AST para levantar chamadas simuladas, por exemplo.
Tenho certeza de que 90% dos usuários do Jest não têm ideia de que seu código foi transformado em AST para levantar chamadas simuladas, por exemplo.
QUE
Tente usar console.debug
ou console.error
Você pode usar --useStderr
no meu caso resolveu o problema porque passa as mensagens diretamente
https://nodejs.org/api/process.html#process_a_note_on_process_i_o
Tenho lutado contra isso novamente hoje e a sinalização --useStderr
corrigiu isso para mim. Obrigado @diomalta!
Eu estava lutando com o mesmo problema, os registros não eram exibidos quando um teste falhava.
Consegui mostrar meu console.log
definindo verbose: true
em meu jest.config
Comentários muito úteis
Estou usando o node v4.4.7 e, no que me diz respeito - não ter nada mostrado no stdout ao usar
console.log
é um problema. Não estou tentando obter ajuda com a codificação, estou relatando o que parece ser um bug para mim. A única outra coisa que mudou é que eu tinha vários arquivos de teste em execução antes, e agora apenas um. deixe-me ver se reativar os outros testes faz com queconsole.log
saídas apareçam novamente.