Jest: console.log não produz resultados durante a execução de testes

Criado em 25 dez. 2016  ·  236Comentários  ·  Fonte: facebook/jest

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 .

  1. Clone https://github.com/udbhav/jest-test
  2. Execute yarn test
  3. Confirme se você não está vendo nada de console.log
  4. Altere a definição de configuração testEnvironment Jest para node
  5. Execute novamente yarn test
  6. Confirme se você está vendo a saída do console.log

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

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 que console.log saídas apareçam novamente.

Todos 236 comentários

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.

screen shot 2016-12-28 at 5 55 29 pm

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:

image

É como se um processo gerasse um erro (tipos de prop com falha), mas ele apenas é escrito pelos logs de saída do teste.

Mais:

image

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:

image

Não consigo escolher nenhum padrão em particular, mas algumas coisas aconteceram (tenho um console.warn('----------------') em um dos meus componentes.)

  • Se eu rolar um pouco para cima a partir da parte inferior quando executo os testes, vejo o log. Se eu rolar para baixo a janela do terminal enquanto os testes estão rolando (para que ele comece a rolagem automática), quando o teste for concluído, eu rolar de volta para cima e a linha console.warn foi embora (presumivelmente sobrescrita).
  • Se eu executar os testes e bater imediatamente em 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.
  • Quando executo 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.
  • O mesmo que o anterior se eu apenas executar 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:

  • Estou executando jest --watch --verbose (v19.0.2)
  • Algumas (mas não todas!) console.log instruções não aparecem, nem durante a execução do teste ou no resumo
  • No meu caso, posso isolá-lo para uma chamada _.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.
  • Se eu invocar a piada com --runInBand , vejo todas as instruções console.log .
  • Ao contrário da maioria dos relatórios anteriores, estou executando "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
    screen shot 2017-03-29 at 3 38 51 pm

  • console.log - mostrado por uma fração de segundo (<0.2s)
    screen shot 2017-03-29 at 3 39 34 pm

  • Depois que o console.log for pintado
    screen shot 2017-03-29 at 3 39 47 pm

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?

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

arquivos

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');
})

Saída

$ 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:

  • Execute testes de Jest de apenas 1 arquivo. Sim ... nada realista, então veja a próxima opção.
  • Use a bandeira --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

  • muitos testes de integração estão falhando agora devido às mudanças necessárias na saída
  • às vezes (infelizmente) a saída do log aparece após a última atualização de status - o motivo é provavelmente o fato de que os fluxos do processo filho são liberados depois que o processo filho envia a mensagem de sucesso ao pai.

@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 esse problema no modo de relógio. Versão 23.6.0

Eu até gravei se alguém quiser ver por si mesmo:
asciicast

como outros, só é apagado quando executado com --watch . Tentei --verbose false e não ajudou.

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

image

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:

  • Nó 10.16.0
  • jest 24.8.0
  • ts-jest: 24.0.2
  • datilografado 3.5.2
  • @ types / jest 24.0.15

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 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"

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.
Jest test console log

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:
image

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.

image

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

  • capturar e mostrar todos os logs capturados para um teste em caso de falha por padrão
  • tem a opção de não mostrar nenhum, e
  • tem a opção de desativar a captura.

é 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

Esta página foi útil?
0 / 5 - 0 avaliações