@thymikee Alguma ideia de por que isso está acontecendo?

Não faço ideia, mas tentaria minimizar o exemplo, por exemplo, removendo o texto datilografado

Eu sou capaz de reproduzir sem Typescript

Pode confirmar que o Node 7.4 come os logs do console, mas funciona no Node 7.5.0, 7.10.0, 8.0.0 e 8.1.2.
Por favor, atualize sua versão do Node. Fechamento

@thymikee E o Nó 6, que é a versão atual do LTS? (Parece que estou acertando isso também, embora ainda não tenha depurado o suficiente. No entanto, estou limitado a versões LTS por enquanto, então não posso atualizar).

Testado na v6.11.0, ainda mostra console.log s.

Ah, eu posso estar enfrentando algum outro problema. Obrigado, @thymikee , vou voltar a depurar um pouco mais.

Eu estava executando o Node 7.3.0 sem saber (versão errada via n) e não estava registrando. Mudou para 8.1.1 e registrou novamente.

@thymikee - não vejo como essa é a solução? ...Não consigo atualizar minha versão do nó

Acho que estou um pouco confuso como isso seria considerado um bug do Node e não pelo menos ter algo a ver com o próprio Jest. Usando o Node v7.4.0, com o Jest v19.0.2 eu vejo o log do console dos meus testes. A simples atualização do Jest para v20.0.4 (sem fazer nenhuma alteração em qualquer outra configuração) faz com que o registro do console não apareça mais. Existe algo que eu estou perdendo?

@thymikee Então, atualizei minha versão do nó e não vejo logs de console no nó 8.2.1 Winx64 + Jest 20.0.4. Eu tenho que usar um fallback por enquanto

  console.log = s => {
    process.stdout.write(s + "\n");
  };

e tenho certeza de que deve ser corrigido no Jest, já que as versões anteriores não apresentavam esse problema.

@nowherenone você pode testar se isso acontece na versão alfa mais recente jest@test ?

@thymikee Apenas tentei com jest@test no nó 8.2.1 mas mesmo resultado. As declarações console.log são sempre engolidas.

@thymikee O problema está no módulo BufferedConsole, onde os parâmetros do construtor do Console não correspondem aos esperados.

Abri um PR, talvez ajude: https://github.com/facebook/jest/pull/4157

Acho que o problema aqui é que o Jest armazena mensagens em buffer, mas há algo que faz com que saia (ou um loop infinito, etc.). Você precisará usar --verbose para imprimir as mensagens diretamente no fluxo de saída.

Isso é ridículo - sou acionado pela quantidade de respostas inúteis de @cpojer (em todas as edições e relações públicas que vou) e tentando colocar tudo em todos os outros como se de alguma forma não fôssemos inteligentes o suficiente.

Não use Jest - essa é a minha resposta se você estiver se perguntando. Encontre uma nova estrutura de teste.

describe('index', () => {
  it('doesnt print anything', () => {
    console.log('Hellllooo');
    expect(true).toBe(true);
  });
});

$ yarn test -- src/__tests__/index.spec.js --verbose
yarn test v0.27.5
warning package.json: No license field
$ jest "src/__tests__/index.spec.js" "--verbose"
 PASS  src/__tests__/index.spec.js
  Index
    ✓ doesnt print anything (2ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        0.969s, estimated 2s

$ jest "--version"
v20.0.4
$ node --version
v7.4.0

Tenho certeza de que vou ser instruído a instalar uma versão mais recente do Node Lmao - que piada 😂 😂 😂

@ nf071590 não pode reproduzir, funciona em repl.it com exatamente as mesmas versões Jest e Node: https://repl.it/KYLc/0

Por favor, faça uma reprodução séria antes de reclamar sobre os mantenedores do projeto.
Saúde!

Não tenho certeza do que fazer sobre isso. Eu literalmente colei seu exemplo em um arquivo e executei o Jest, e ele funciona como anunciado no meu Mac, com a versão master mais recente do Jest há um minuto. Ver:

Jogando desde que estou no Windows (nó 8.4, jest 21.0.0-alpha.2), console.log s são _às vezes_ ocultos se você não usar --verbose , mas parecem mostrar consistentemente com isso. Feliz em atualizar com os resultados usando o nó 7 e o jest estável quando chegar um minuto.

O mesmo problema aqui.

describe('index', () => {
  it('doesnt print anything', () => {
    console.log('Hellllooo');
    expect(true).toBe(true);
  });
});

$ node --version
v7.4.0
$ jest "--version"
v21.1.0

Atualmente encontrando o mesmo problema no nó v8.7.0 (npm v5.4.2).

Isso ainda é um problema

Você pode fornecer uma reprodução?

FWIW, acabei aqui porque estava tendo exatamente o mesmo problema. Nó v7.4.0. Atualizei minha versão do Node e console.log imprime como esperado agora, mesmo sem --verbose . A V7.4.0 pode não ser a única versão a ter esse problema, mas parece estar relacionada à versão e não é um problema para algumas versões do Node. Agora estou no Node v8.3.0, que parece funcionar.

Dito isso, antes da atualização eu tinha as mesmas versões que @nf071590 e os mesmos problemas. Não sei por que isso não acontece no repl.it, mas não é uma coisa estranha acontecendo apenas no computador dele.

Posso reproduzir isso com o nó 8.9.0 e jest 21.2.1, macOS 10.12.6 (16G1036)

@SimenB Eu poderia, mas parece que essa questão foi discutida até a morte aqui e em outros lugares. A natureza do processo multi-(filho) do jest significa que ele substituirá console.logs , e sem uma reescrita massiva, isso não mudará. Qualquer pessoa que venha a este tópico e queira evitar o problema de usar o sinalizador --verbose não permite a depuração com console.log , deve usar o sinalizador --watch . Isso evitará que os processos de trabalho filho sejam substituídos e permitirá que você veja a saída detalhada com os logs do console. --watch é muito rápido e agrega mais valor ao focar a atenção nos testes e códigos que foram alterados, executando apenas os testes que foram alterados ao salvar.

No meu caso, descobri que as mensagens detalhadas comeriam algumas, mas não todas as mensagens console.log . Eu removi a opção detalhada e parece funcionar um pouco!

Acabei de atualizar minha versão do nó de v6 para v9 e um dos meus arquivos de teste está consolando.

Estou lutando com o problema há semanas. Estou feliz que agora funcione

O problema ainda persiste com --verbose quando combinado com --forceExit - acho que a razão para isso é que console.log sai para stdout enquanto jest escreve para stderr e quando --forceExit ainda pode haver conteúdo em stdout que não seja liberado

Eu encontrei a seguinte solução (sem a necessidade de --verbose ) para corrigir console.log não mostrando e/ou console.log sendo armazenado em buffer e não exibido ao vivo

comando
jest .... --forceExit --setupTestFrameworkScriptFile ./src/tests/jestShim.js

conteúdo de jestShim.js

const { Console } = require('console');
global.console = new Console(process.stderr, process.stderr);

Mesmo problema - nunca veja a saída do console.log.

Node 9.80 Jest 22.4.2 Mac OS 10.13.3

Nenhuma das soluções sugeridas aqui funcionou para mim.

Como sempre, crie uma reprodução que possamos baixar para testar. Eu não encontrei esse problema, então não tenho certeza de como começar a corrigi-lo

A solução alternativa do @ledbit funcionou para mim
NPM 5.3.0
brincadeira 22.4.3

• Mac OS

Ainda estou a ponto de precisar de uma reprodução.

--forceExit parece um pouco quebrado, mas não o encontrei quando não estiver usando esse sinalizador

[Usando react-scripts bifurcado para usar o Jest v23.0.0 mais recente, nó v8.11.2]

Eu finalmente consegui que os logs aparecessem 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 nos testes e um resumo final do teste), mas é a única coisa que funcionou até agora. Eu tentei de tudo nos comentários acima. Observe que o argumento --verbose é necessário para esta solução (e está sendo combinado implicitamente com --watch via react-scripts ).

Isso ainda é um problema. Estou usando jest v22.4.3 no Node 10.1.0 e vejo apenas a primeira instrução console.log do meu aplicativo, todo o resto é ignorado. Quando defino minha biblioteca de log para transmitir para stdout, posso ver alguns dos logs, mas eles não aparecem na ordem correta.

O trabalho de Jest como executor de testes é nos ajudar a depurar e corrigir nosso código. Isso simplesmente não pode ser alcançado sem logs.

@thymikee , por favor, reabra este problema

@thanpolas sinta-se à vontade para criar um novo problema com um repositório mostrando o bug para que possamos investigar :). Além disso, use o Jest 23, pois é o mais recente.

Eu descobri meu problema, o log estava acontecendo através de um logger que estava transmitindo para stdout, quando redirecionado para console.log eu esqueci de invocar o retorno de chamada do stream writer para que o stream parasse de enviar logs.

Por que vale a pena, vi diferenças entre o Terminal e o iTerm2.

Acho que uma opção de instruir o jest a não fazer mágica no stdout e no console seria muito benéfico para todos

Aqui está uma instância do bug que eu consegui reproduzir. Não tenho certeza se existem várias fontes:

https://github.com/spion/jest-logging-repro

yarn install; yarn repro

Configuração: Jest está no modo de observação, com o sinalizador detalhado ativado, com pelo menos dois arquivos de teste em execução.

Teoria: A saída de um dos trabalhadores move o cursor do console para o local errado, substituindo o conteúdo errado.

Observação no console:

 RUNS  tests2/other-tests.js
 RUNS  lib/example.spec.js
 PASS  tests2/other-tests.js
  bar
    ✓ always is true (17ms)

 PASS  lib/example.spec.js
  foo
    ✓ adds 5 (5ms)

Test Suites: 2 passed, 2 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        1.673s
Ran all test suites.

Watch Usage: Press w to show more.

Se eu remover o log do console, visualmente "RUNS" será substituído conforme o esperado:

 PASS  lib/example.spec.js
  foo
    ✓ adds 5 (5ms)

 PASS  tests2/other-tests.js
  bar
    ✓ always is true (5ms)

Test Suites: 2 passed, 2 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        1.597s
Ran all test suites.

Watch Usage: Press w to show more.

Se eu adicionar 3 logs do console:

 PASS  lib/example.spec.js
  foo
    ✓ adds 5 (5ms)


 RUNS  tests2/other-tests.js

Test Suites: 1 passed, 1 of 2 total
Tests:       1 passed, 1 total
Snapshots:   0 total
  console.log tests2/other-tests.js:5
    JEST

 PASS  tests2/other-tests.jsests.js:6
  bar
    ✓ always is true (19ms)

Test Suites: 2 passed, 2 total
Tests:       2 passed, 2 total
Snapshots:   0 totalTime:        1.788sRan all test suites.

Watch Usage: Press w to show more.

Versão do nó:

30656 % node --version
v8.11.2

Acho que a @spion está se aprimorando nisso. Boa reprodução fácil.

Pode confirmar que isso acontece no Node v8.11.1 LTS e só acontece no modo watch e watchAll . sem modos de relógio, tudo bem.

Eu tenho o mesmo problema com o Node v10.6.0 e Jest 23.4.1

Sim eu também. Acabei de descobrir que -w 1 faz o log funcionar novamente, o que se encaixa na hipótese de @spion .

nó 8.11.3
brincadeira 23.4.0

Estou encontrando esse problema, ou pelo menos um problema semelhante, quando ativo a correspondência de regex de arquivo (pressionando p no modo watch ). Com all ativado, os logs são impressos conforme o esperado. Nota --verbose não está aqui.

Amostra 1

it.only(`should display a ErrorMessage component if state.validated is 'error'`, () => {
    const fV = shallow(<FormValidator/>);
    console.log('r1');
    console.error('r2');
    console.error('r3');
    ...

Com all assistindo (imprime log s e error s:

 PASS  src/components/__tests__/FormValidator.js
  ● Console

    console.log src/components/__tests__/FormValidator.js:56
      r1
    console.error src/components/__tests__/FormValidator.js:57
      r2
    console.error src/components/__tests__/FormValidator.js:58
      r3

No modo file regex (só imprime os primeiros log e não os error s):

Test Suites: 0 of 1 total
Tests:       0 total
Snapshots:   0 total
  console.log src/components/__tests__/FormValidator.js:56
    r1

 PASS  src/components/__tests__/FormValidator.jsidator.js:57
  FormValidator
    ○ skipped 3 tests
  FormValidator.displayMessage
    ✓ should display a ErrorMessage component if state.validated is 'error' (32ms)
    ○ skipped 5 tests
  FormValidator.render
    ○ skipped 1 test

Amostra 2

it.only(`should display a ErrorMessage component if state.validated is 'error'`, () => {
    const fV = shallow(<FormValidator/>);
    console.log('r1');
    console.error('r3');
    ...

all (imprime log e error conforme esperado):

 PASS  src/components/__tests__/FormValidator.js
  ● Console

    console.log src/components/__tests__/FormValidator.js:56
      r1
    console.error src/components/__tests__/FormValidator.js:59
      r3

watch (nada é impresso com o código acima):

Snapshots:   0 total
 PASS  src/components/__tests__/FormValidator.jsator.js:56
  FormValidator
    ○ skipped 3 tests
  FormValidator.displayMessage
    ✓ should display a ErrorMessage component if state.validated is 'error' (20ms)
    ○ skipped 5 tests
  FormValidator.render
    ○ skipped 1 test

Test Suites: 1 passed, 1 total

Amostra 3

it.only(`should display a ErrorMessage component if state.validated is 'error'`, () => {
    const fV = shallow(<FormValidator/>);
    console.log('r1');
    console.log('r2');
    console.log('r3');
    console.log('r4');
    ...

all (imprime todos os quatro log s esperados):

 PASS  src/components/__tests__/FormValidator.js
  ● Console

    console.log src/components/__tests__/FormValidator.js:56
      r1
    console.log src/components/__tests__/FormValidator.js:57
      r2
    console.log src/components/__tests__/FormValidator.js:58
      r3
    console.log src/components/__tests__/FormValidator.js:59
      r4

watch (somente os dois primeiros log s são impressos com o código acima):

Snapshots:   0 total
  console.log src/components/__tests__/FormValidator.js:56
    r1

  console.log src/components/__tests__/FormValidator.js:57
    r2

 PASS  src/components/__tests__/FormValidator.jsator.js:58
  FormValidator
    ○ skipped 3 tests
  FormValidator.displayMessage
    ✓ should display a ErrorMessage component if state.validated is 'error' (31ms)
    ○ skipped 5 tests
  FormValidator.render
    ○ skipped 1 test

Test Suites: 1 passed, 1 total

Não tenho certeza do que fiz, mas acho que a ordem de como você monta a brincadeira é importante. Eu acho que algumas configurações podem substituir umas às outras. Estou recebendo o teste e a saída de log.

node -v v8.11.2
jest -v 23.4.0

Abaixo está minha configuração do jest no meu package.json

```
"brincadeira": {
"transformIgnorePatterns": [
"/node_modules/"
],
"setupFiles": [
"/src/setupTests.js"
],
"testEnvironment": "jsdom",
"verboso": verdadeiro,
"projetos": [
{
"displayName": " COMPONENTES ",
"setupFiles": [
"/src/setupTests.js"
],
"modulePaths": ["/src/"],
"testeMatch": ["/src/components/__tests__/ / .test.js"]},{"displayName": " REDUCERS ","setupFiles": ["/src/setupTests.js"],"modulePaths": ["/src/"],"testeMatch": ["/src/reducers/__tests__/ /.test.js"]
},
{
"displayName": " AÇÕES ",
"setupFiles": [
"/src/setupTests.js"
],
"modulePaths": ["/src/"],
"testeMatch": ["/src/actions/__tests__/ */ .test.js"]
}
]
},

Here are my dependencies

"dependências": {
"babel-core": "^6.26.3",
"babel-jest": "^23.4.0",
"babel-loader": "^7.1.5",
"babel-preset-env": "^1.7.0",
"babel-preset-react": "^6.24.1",
"dotenv": "^6.0.0",
"expresso": "^4.16.3",
"brincadeira": "^23.4.0",
"reagir": "^16.4.1",
"react-dom": "^16.4.1",
"react-redux": "^5.0.7",
"react-scripts": "1.1.4",
"redux": "^4.0.0",
"regenerator-runtime": "^0.12.0"
},

output from just running jest

APROVAÇÃO REDUCERS src/reducers/__tests__/comments/index.test.js
✓ lida com ações do tipo SAVE_COMMENT (4ms)
✓ lida com ação com tipo desconhecido

AÇÕES DE PASSAGEM src/actions/__tests__/index.test.js
salvarComentário
✓ tem o tipo correto (1ms)
✓ tem a carga útil correta (1ms)

PASS COMPONENTS src/components/__tests__/App/index.test.js
✓ Deve mostrar um CommentList (5ms)
✓ Deve mostrar um CommentBox (1ms)

PASS COMPONENTS src/components/__tests__/CommentBox/index.test.js
✓ tem uma área de texto (23ms)
✓ tem um botão (3ms)
a área de texto
✓ tem uma área de texto que os usuários podem digitar (9ms)
✓ quando o formulário é enviado, a área de texto é esvaziada (5ms)

PASS COMPONENTS src/components/__tests__/CommentList/index.test.js
✓ cria um LI por comentário (32ms)

Conjuntos de teste: 5 aprovados, 5 no total
Testes: 11 aprovados, 11 no total
Instantâneos: 0 no total
Tempo: 3,79s
Executou todas as suítes de teste em 3 projetos.
console.log src/components/__tests__/CommentList/index.test.js:26
0

console.log src/components/__tests__/CommentList/index.test.js:27
Teste

```

Este problema deve ser reaberto, a saída do console também foi engolida pelo jest, meu ambiente é:

→ nó --versão
v8.11.3

→ npx jest --versão
23.4.1

Eu tentei com uma configuração limpa e tudo funciona bem.

// console.test.js
describe('jest should console output', () => {
  test('should console.log output be print', () => {
    console.log('console.log')
    expect(1).toBe(1)
  })

  test('should console.error output be print', () => {
    console.error('console.error')
    expect(1).toBe(1)
  })

  test('should console.info output be print', () => {
    console.info('console.info')
    expect(1).toBe(1)
  })
})

saída:

Então eu pensei que o problema poderia estar relacionado à minha configuração do jest:

{
  "globals": {
    "API_SERVER_PLACEHOLDER": "SOME_API_ADDRESS"
  },
  "moduleFileExtensions": [
    "js",
    "jsx"
  ],
  "transform": {
    "^.+\\.jsx?$": "babel-jest"
  },
  "moduleNameMapper": {
    "\\.(css|less|sass|scss|png)$": "<rootDir>/__mocks__/styleMock.js",
    "\\.(gif|ttf|eot|svg|png)$": "<rootDir>/__mocks__/fileMock.js"
  }
}

Meu instinto me disse para verificar verbose e depois de removê-lo está tudo bem.

recapitular

jest versão 23.4.1 com configuração verbose definida como true faria com que a saída do console fosse engolida.

proponha alterar o fluxo de saída padrão para stdout : https://github.com/noscripter/jest/pull/1

Está quebrado de novo?! Por que isso continua quebrando?

Eu trabalhei em torno disso com:

expect(str).toBe("not this");

😬

Se você tiver verbose: true em seu package.json, ou estiver executando jest com o sinalizador --verbose (ou ambos?), tente removê-los.

Esquece que isso não ajuda mais.

Muitas vezes, posso ver a saída do log por uma fração de segundo _antes_ do resumo completo do teste ser impresso no console. Estou tendo que console.log cerca de 4-5 vezes seguidas para mostrar a saída, e mesmo assim o último log será cortado pela metade (por exemplo, ao imprimir um objeto grande, apenas a primeira metade será ser visível no último log impresso).

Também é muito difícil prever. Às vezes, um ou dois console.log s serão suficientes, enquanto outras vezes tenho que colocar de três a cinco seguidos. Também não importa se meus logs estão no código que estou testando ou nos próprios casos de teste.

Parece que o jest está imprimindo os logs e limpando a saída antes de imprimir o resumo completo do teste, quando na verdade deveria reter esses logs.

Eu aceitei neste ponto que eu tenho que copiar e colar os logs várias vezes para vê-los no console.

console.log funciona se você executar apenas um arquivo de teste específico

yarn test <your-test-file-name>

por exemplo
yarn test FormValidator

FYI eu corro meu repro com o seguinte comando:

script -qfc 'yarn repro' /dev/null > raw.log

Isso é zsh - você pode querer script -qfce no bash

e então eu vi o log com cat -vet raw.log . Aqui estão os resultados:

^[[2K^[[1G^[[1myarn run v1.7.0^[[22m^M$
^[[2K^[[1G^[[2m$ jest --watch^[[22m^M$
^[[2J^[[3J^[[H^[[1m^[[2mDetermining test suites to run...^[[1m^[[22m^[[999D^[[K^M$
^M$
^[[1mTest Suites: ^[[22m0 of 2 total^M$
^[[1mTests:       ^[[22m0 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        0s, estimated 1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mlib/^[[22m^[[1mexample.spec.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m0 of 2 total^M$
^[[1mTests:       ^[[22m0 total^M$^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        0s, estimated 1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^[[0m^[[7m^[[1m^[[32m PASS ^[[39m^[[22m^[[27m^[[0m ^[[2mlib/^[[22m^[[1mexample.spec.js^[[22m^M$
^M$^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mlib/^[[22m^[[1mexample.spec.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m0 of 2 total^M$
^[[1mTests:       ^[[22m0 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        0s, estimated 1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A  foo^M$
^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mlib/^[[22m^[[1mexample.spec.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m0 of 2 total^M$
^[[1mTests:       ^[[22m0 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        0s, estimated 1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A    ^[[32mM-bM-^\M-^S^[[39m ^[[2madds 5 (4ms)^[[22m^M$
^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mlib/^[[22m^[[1mexample.spec.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m0 of 2 total^M$
^[[1mTests:       ^[[22m0 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        0s, estimated 1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M$
^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mlib/^[[22m^[[1mexample.spec.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m0 of 2 total^M$
^[[1mTests:       ^[[22m0 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        0s, estimated 1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mlib/^[[22m^[[1mexample.spec.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m0 of 2 total^M$
^[[1mTests:       ^[[22m0 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        0s, estimated 1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 of 2 total^M$
^[[1mTests:       ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        1s^[[999D^[[K  ^[[2mconsole.log^[[22m ^[[2mtests2/other-tests.js:5^[[22m^M$
    JEST^M$
^M$
^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^[[0m^[[7m^[[1m^[[32m PASS ^[[39m^[[22m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 of 2 total^M$
^[[1mTests:       ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A  bar^M$
^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 of 2 total^M$
^[[1mTests:       ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A    ^[[32mM-bM-^\M-^S^[[39m ^[[2malways is true (15ms)^[[22m^M$
^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 of 2 total^M$
^[[1mTests:       ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M$
^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 of 2 total^M$
^[[1mTests:       ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^[[999D^[[K^[[1mTest Suites: ^[[22m^[[1m^[[32m2 passed^[[39m^[[22m, 2 total^M$
^[[1mTests:       ^[[22m^[[1m^[[32m2 passed^[[39m^[[22m, 2 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        1.128s^M$
^[[2mRan all test suites^[[22m^[[2m related to changed files^[[22m^[[2m.^[[22m^M$
^M$
^[[1mWatch Usage^[[22m^M$
^[[2m M-bM-^@M-: Press ^[[22ma^[[2m to run all tests.^[[22m^M$
^[[2m M-bM-^@M-: Press ^[[22mf^[[2m to run only failed tests.^[[22m^M$
^[[2m M-bM-^@M-: Press^[[22m p ^[[2mto filter by a filename regex pattern.^[[22m^M$
^[[2m M-bM-^@M-: Press^[[22m t ^[[2mto filter by a test name regex pattern.^[[22m^M$
^[[2m M-bM-^@M-: Press^[[22m q ^[[2mto quit watch mode.^[[22m^M$
^[[2m M-bM-^@M-: Press ^[[22mEnter^[[2m to trigger a test run.^[[22m^M$

Espero que isto ajude. Parece que há uma contagem incorreta de códigos de controle em um determinado ponto.

O resultado final fica assim:

 PASS  lib/example.spec.js
  foo
    ✓ adds 5 (4ms)


 RUNS  tests2/other-tests.js

 PASS  tests2/other-tests.js2 total
  bar
    ✓ always is true (15ms)

Test Suites: 2 passed, 2 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        1.128s
Ran all test suites related to changed files.

Watch Usage
 › Press a to run all tests.
 › Press f to run only failed tests.
 › Press p to filter by a filename regex pattern.
 › Press t to filter by a test name regex pattern.
 › Press q to quit watch mode.
 › Press Enter to trigger a test run.

A linha do console está ausente e o pass está escrito duas linhas muito abaixo, provavelmente devido ao entrelaçamento com o console.log não sendo levado em consideração ao subir para exibir o "PASS"

edit: Adicionado este resumo em uma essência para facilitar a pesquisa e manipulação: https://gist.github.com/spion/bbb34c5abc1230a37ad5f4f01336b8df

ps Para reproduzir isso com o mestre atual, pode ser necessário alguma coerção. Quando você entrar no modo de observação, pressione e segure "a" por um tempo - o console.logs começará a ficar fora de controle em algum momento (aparecerá em lugares e horários inesperados)

Também esqueci - estou no ubuntu bionic, se isso faz alguma diferença no comportamento do terminal WRT:

% lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.1 LTS
Release:    18.04
Codename:   bionic

Eu também. @spion acertou em cheio no que estou vendo. Eu só descobri porque tenho testes em código lento e assíncrono. Vejo a saída do console e ela é substituída pelo resumo dos resultados do teste.

Por que vale a pena, eu reverti para [email protected] e isso resolve os problemas que eu estava tendo com a saída do resumo do teste sendo escrita sobre a saída do console em [email protected] .

Atualização - Acredito que encontrei um patch mínimo que faz algum progresso, mas demorei um pouco para entender a interação entre os repórteres do Jest e o gerador de status

Jest monkey-patches os métodos de gravação dos fluxos stderr e stdout do processo com seu próprio gravador. Esse escritor anota a saída de jest-cli Status.js, que contém coisas como o número de testes em andamento, uma barra de progresso, o tempo decorrido e assim por diante.

Sempre que houver uma instrução de gravação nesse fluxo, essa instrução será substituída por uma instrução "delete" para o status (subindo usando códigos de controle ANSI), a gravação original e uma instrução "escrever o status novamente". Daí a ilusão de que o status está sempre na parte inferior da tela, enquanto o texto rola acima dela.

(Claro, é um pouco mais inteligente do que isso - as gravações são armazenadas em buffer e os dados em buffer são realmente gravados uma vez a cada 100ms junto com o status)

No entanto, o executor de teste paralelo (usado no modo de observação, que define runInBand como false) executa outros workers. Esses trabalhadores são configurados para "herdar" o fluxo stdio do processo original. Infelizmente, isso não significa que eles herdam a versão corrigida que atualiza o status! Se essas gravações acontecerem, elas serão

1. adicionado após o status (o status não é apagado)
2. será apagado no próximo apagamento de status (tornando o status anterior parcialmente visível também, já que o apagamento não sobe o suficiente para apagar tanto a saída do console quanto a atualização de status antiga)

Para garantir que a versão corrigida receba essas gravações tty, é necessário alternar os fluxos de processos filhos do modo "herdar" para o modo "pipe". Dessa forma, as saídas do processo estão disponíveis como fluxos no processo filho, em vez de ir diretamente para o stdout/stderr principal. Também precisamos canalizar manualmente os fluxos:

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

A canalização manual dos fluxos garante que a gravação com patch de macaco seja chamada pelo nó.

Isso quebra muitos testes de integração, mas eles são quebrados principalmente devido à falta de cor. Fazendo

diff --git a/packages/jest-worker/src/worker.js b/packages/jest-worker/src/worker.js
index 5eee64af..5e5126eb 100644
--- a/packages/jest-worker/src/worker.js
+++ b/packages/jest-worker/src/worker.js
@@ -94,6 +94,8 @@ export default class {
         {
           cwd: process.cwd(),
           env: Object.assign({}, process.env, {
+            // $FlowFixMe: Does not know about isTTY
+            FORCE_COLOR: process.stdout.isTTY,
             JEST_WORKER_ID: this._options.workerId,
           }),
           // Suppress --debug / --inspect flags while preserving others (like --harmony).

reduz esse número significativamente, mas ainda é bastante alto:

Test Suites: 51 failed, 232 passed, 283 total
Tests:       149 failed, 7 skipped, 2706 passed, 2862 total
Snapshots:   19 failed, 17 obsolete, 996 passed, 1015 total

Eu não acho que haja uma maneira de contornar isso - a saída é drasticamente alterada, pois muito mais gravações acabam adicionando a atualização de status agora.

edit: há também o problema de o nó liberar o fluxo de saída muito tarde em determinadas situações, muito tempo depois que o processo filho enviou uma mensagem de sucesso para o pai.

por favor corrijam, isso realmente prejudica a produtividade com brincadeira

O downgrade para [email protected] traz de volta a saída do log do console. Tive que definir o nó --env para fazê-lo funcionar. Por favor, corrija isso.

Atualmente, parece que a única maneira de obter o log do console para ser confiável é registrar a mesma coisa 3-4 vezes seguidas. Jest só irá bloquear um certo número deles. Ainda muito irritante.

Existe alguma atualização sobre isso? Estou executando o jest 23.4.1 e o nó 9.11.1 e às vezes estou obtendo a saída do log do console e às vezes não.

Dois anos sem logs de console me tornaram um desenvolvedor melhor. Obrigado equipe Jest!

Eu não posso acreditar que isso ainda é um problema. Por que o assunto está encerrado?

Quero dizer, quem iria querer depurar seus testes com falha, certo?

Como @jonogilmour mencionou, se eu registrar algo uma vez que não seja exibido, mas registrar as coisas duas vezes, farei com que um deles seja exibido.

FWIW, a solução --verbose=false funciona para mim. No meu package.json :

"scripts": {
...
    "test": "react-scripts test --env=jsdom --verbose=false",

Algumas outras observações:

• A remoção de --env=jsdom (não é uma opção para meu aplicativo real) fez com que funcionasse sem --verbose=false.
• Executando o teste diretamente com jest (não através de scripts de reação) também funcionou.
• Quando uma asserção falha e você obtém muito mais saída do jest, muito mais logs do console também são substituídos.

Olá rapazes/meninas,
Também encontrei o famoso problema de log do console jest ao executar testes no modo --watch.
A solução foi usar --watchAll em vez de --watch. O resumo dos testes ficou mais feio, mas os logs mostraram como esperado.

Mac OS High Sierra
nó v8.11.3
brincadeira: 23.6.0
ts-jest: 23.10.4

Pra mim isso em beforeAll

  console.log = s => {
    process.stdout.write(s + "\n");
  };

e isso no shell fez o trabalho:

yarn test > test.log

Para mim, mudar para mocha resolveu o problema. É muito trivial trocar, já que o DSL é muito parecido. Você pode até continuar usando a biblioteca expect do JEST: https://www.npmjs.com/package/expect

É quase tão fácil quanto remover jest e instalar mocha .

Edit: Spam ou não, é a solução mais fácil aqui.

Este problema está realmente doendo, eu gostaria que os mantenedores pudessem consertar isso o mais rápido possível, porque Jest é para aumentar a produtividade, não o contrário certo?

De qualquer forma, o seguinte é o que estou usando write agora:

export const log = (s: any) => {
    console.log(s);
    console.log(s);
    console.log(s);
    process.stdout.write(s + "\n");
};

Você tem que spam sua saída.

Confirmado que --verbose=false corrige o problema.

--verbose=false não funciona para mim com a versão 23.6.0

OMG isso é uma dor :/ novembro 2018

Por favor, reabra este problema

tente colocar silent: false em jest.config.js ... no meu caso me ajudou

Nenhuma das soluções funciona.
NodeJS: v8.12.0
Brincadeira: v23.4.1

Estou usando o Jest há meses e é ótimo e, embora esse bug seja _super irritante_ , a solução que sempre usei é fazer uma declaração de lixo, pois isso será registrado no console todas as vezes.

Exemplo, ao tentar desconectar uma chamada simulada:

expect('hello').toEqual(childFunc.mock.calls[0]) imprime:

Não é o ideal, mas faz o trabalho e me permite terminar de escrever meus testes.

Executando o Jest com um sinalizador --watch.
Jest versão 23.5.0
Versão do nó 8.11.3

Este é um exemplo decente de "muita magia" acontecendo debaixo do capô, e as consequências disso quando algo dá errado. Não estou convencido de que agrupar a saída console.log valha um ano e meio de instruções console.log ausentes. 😕

Concordo com o que foi dito acima - isso não é um espetáculo, mas torna Jest doloroso de uma maneira completamente desnecessária.

Minha "solução" é que grande parte da lógica usa log4js , então, para onde eu dou o Jest ao código do lado do servidor, estou bem. Infelizmente, tenho uma grande quantidade de código do lado do cliente, onde costumo copiar e colar quatro cópias de cada console.log pois eventualmente uma delas parece aparecer.

Usar expect para registrar informações é uma boa solução se você estiver logando de dentro de um teste (especialmente porque você pode criar um snippet para ele com uma palavra-chave como logjest em seu editor), mas isso fica aquém sempre que você precisa ir mais fundo e registrar de dentro das funções reais que seus testes estão chamando.

Que tal CI=true yarn run test ?

Desculpe pelo que disse antes, mas funciona bem sem o título dos casos de teste, quer dizer, sem a opção "--verbose", acho que --verbose faz algum tipo de formatação e substitui o stream stdout.
Então, para mim, eu tenho como 2 meses e tudo está funcionando bem.
E se alguém quiser usar essa opção, basta anexá-la aos seus comandos npm assim: npm run test:integration -- --watchAll --verbose --coverage --etc

As pessoas com o problema podem testar [email protected] ? Inclui #6871

@jamesta696 Oi, acho que você precisa postar esse tipo de pergunta no StackOverflow usando a tag "jest" aqui porque as discussões aqui são para "problemas", no entanto, sei que alguém poderia ajudá-lo, mas o problema aqui poderia ser encerrado porque a questão principal não está sendo discutida.
E por enquanto, não posso te responder essa pergunta porque não estou desenvolvendo algo para react e frontend, também, não sou membro do jest, mas vamos tentar seguir as regras.

@SimenB Atualizei o jest (para sua versão mencionada) e tentei colocar algumas instruções console.log no meu projeto que tiveram o problema. Até agora, parece estar corrigido: Todos os console.log s aparecem. Vou continuar a usá-lo e informá-lo se encontrar o problema novamente.

FYI: Eu estava (e ainda estou) usando jest --watchAll

@tobyhinloopen Legal ver uma prova do progresso que mencionou @SimenB .

isso é incrível @tobyhinloopen!

Também posso confirmar que [email protected] funciona bem e você pode ver todos os logs do console sem --verbose=false.

Também posso confirmar que [email protected] funciona bem e você pode ver todos os logs do console sem --verbose=false.

+1. também pode confirmar. feliz em ver que isso está funcionando. bom trabalho, pessoal Jest! 😄

Posso confirmar também! É como o Natal. 🎅

😃

não precisa esperar até as atualizações do app create-react

Estou executando a versão do jest 24.0.0 , mas ainda não consigo ver console.log ou console.error . Me perguntando o que posso estar fazendo de errado.

Certifique-se de que eles não sejam ridicularizados

Isso é realmente estranho. Parece haver um problema com o manuseio assíncrono. Não consigo exibir os erros. Mesmo se agrupado em blocos try/catch , não consigo ver o erro.

O parâmetro generator está correto com certeza, se eu remover a chamada de função assíncrona, ela será registrada corretamente. Ele também retorna a string correta quando está fora do loop for.

A versão do Jest é 24.0.0 , o nó é 10.5

@tiborsaas Seu teste provavelmente terminará antes da execução de console.log .
Se você quiser esperar pela iteração em changedGenerators , precisará de algo como

await Promise.all(changedGenerators.map(async (generator) => {/* ... */}))

Obrigado pela resposta, mas não é bem o caso, algum erro impede que o console.log seja exibido. Existe outra função assíncrona que funciona bem com console.log se eu a chamar no retorno de chamada forEach .

Edit: na verdade, por depuração linha por linha, sei que o problema é com

const archives = await fs.readdir(archiveDir);

No entanto, esta questão de brincadeira é sobre registrar coisas. Não quero atrapalhar a conversa.

Você ainda pode estar enfrentando um bug, só queria apontar (sem saber seu código exato) que geralmente é uma má ideia em geral bifurcar um monte de promessas como essa sem aguardá-las, porque elas podem rejeitar após o término do teste: )

Eu concordo, mas quero executar as chamadas expect no forEach porque não sei de antemão com quantas mudanças tenho que lidar.

Infelizmente a abordagem Promise.all não resolveu nada.

Você usou map em vez de forEach ? O objetivo é retornar uma matriz de promessas para Promise.all

@SimenB sim, eu sei.

Se houver um erro, não consigo vê-lo.

@tiborsaas Você não está esperando Promise.all para completar: use await Promise.all(...)

Fiz isso também, mesmo resultado. :(

e se você adicionar await new Promise((resolve) => setTimeout(resolve, 1000)) abaixo de seu promise.all ?

Você pode abrir uma nova edição com uma reprodução? Acredito que o problema relatado pelo OP foi corrigido enquanto você está vendo um diferente (não importa se você lida com assíncrona corretamente ou não, você ainda deve ver a instrução de log)

Sim, é realmente estranho, algo como

test('stuff', () => {
    setTimeout(() => console.log('hi', 500));
})

geralmente ainda é impresso de alguma forma

Ele está usando uma função de retorno de chamada como segundo argumento de Promise.all([...], callback) . Ele deve usar Promise.all([...]).then(callback) . Talvez isso resolva o problema dele, acho que o 2º argumento de .all é ignorado e nunca executado (portanto, seus logs nunca serão executados). @tiborsaas

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all

Sim, isso está errado, mas as instruções de log ainda devem aparecer

@SimenB Não, o segundo argumento é ignorado.

> Promise.all([Promise.resolve(true)], () => console.log("hi")).then(console.log, console.error);
Promise {
  <pending>,
  domain: 
   Domain {
     domain: null,
     _events: { error: [Function: debugDomainError] },
     _eventsCount: 1,
     _maxListeners: undefined,
     members: [] } }
// output:
// [ true ]

Sim, confundi com isso, desculpe. Obrigado @tobyhinloopen

const lol = await Promise.all(versions); funcionou como esperado.

Nesse caso, as instruções de log podem ser perdidas, pois a função nunca é chamada, mas você ainda deve ver as instruções de log no caso forEach original, pois o nó aguardará a conclusão das promessas antes de sair do processo. Então ainda é um bug, mesmo sendo um erro do usuário

RP: # 7731

Eu uso https://www.npmjs.com/package/debug para fazer o log. Isso funcionaria com Jest?

Não, não até que façamos #6524.

Eu recomendo zombar de debug em seus testes e usar console.log se você quiser vê-los

Para referência, as mensagens do console podem ser perdidas se forem impressas após a conclusão dos testes, veja os comentários na parte inferior de #7731. Esta pode ser a razão para algumas, mas provavelmente não para todas as mensagens de console ausentes relatadas aqui.

O --verbose funcionou para mim. Antes de usar --verbose, algumas, mas nem todas as mensagens foram perdidas. Estou usando o nó v10.15.3 e jest v21.2.1

Ainda é um problema para mim, os logs do console não são exibidos no Jest

apesar do último anúncio no blog que o problema foi finalmente resolvido, o problema ainda existe, meus logs do console as vezes não aparecem novamente, estou usando jest v24.8.0 .

E meus trabalhos muito bem 🤷‍♂️. Por favor, poste uma reprodução para que possamos investigar. Não somos assistentes, não podemos ver seu código que está falhando ao registrar a saída.

na verdade, após investigação, os logs relacionados ao teste de API (como supertest) não funcionam. esperado :/

@thymikee Isso está acontecendo de forma inconsistente, então é muito difícil reproduzi-lo. exemplo:
seguintes execuções selecionando um único arquivo de testes (opção p)

• console.log('pantz') (funciona)
• alterar console.log(myObject) (não está funcionando)
• alterá-lo para caber (não está funcionando)
• mude para console.log('pantz') (não está funcionando)
• alterar o ajuste para ele (não está funcionando)
• reinicie o jest (não está funcionando)
• alterá-lo para caber (funcionando)

Agora tentei replicar os mesmos passos e o resultado é inconsistente.

Forneça um repositório de amostra onde não esteja funcionando para que os caras do JEST possam ajudar a depurar isso. @kresli

Há muitas possibilidades de erro do usuário também, principalmente faltando await ou console.log assíncronos.

Vou tentar encontrar um tempo para reproduzir isso então. Até então eu descobri que meus logs são consumidos pelos resultados, como você pode ver abaixo. Antes que FAIL apareça você pode ver meus 2 logs lá. E também vale a pena mencionar que apenas 2 logs são removidos. Se eu adicionar 10 logs um sob o outro, 8 serão mostrados. Acho que é um bom começo :)

Enquanto isso, se você precisar de uma correção abrangente que simplesmente funcione, você pode usar algo como winston para logar no arquivo e no console. Mesmo que as mensagens do console não sejam exibidas, elas são gravadas no arquivo.

Com winston você pode configurar o que deseja registrar onde e suporta vários transportes, e transportes que você mesmo pode implementar.

const logger = winston.createLogger({
  level: "verbose",
  format: winston.format.json(),
  defaultMeta: {},
  transports: [
    new winston.transports.Console(),
    new winston.transports.File({ filename: "combined.log" }),
  ],
});

logger.error(stuff)

Talvez você possa até fazer algo sujo como substituir console.* globalmente para o registrador de winston.

@kresli qual é a sua versão de brincadeira? Isso parece comportamento v23

Isso continua acontecendo comigo com jest v^24.6.0 e node v10.14.2 . Alguma ideia do porquê?

@yaelz Este é um problema de stubbern que geralmente é causado por erro do usuário, mas também tem um histórico de bugs difíceis de reproduzir.

Acho que realmente ajudaria os contribuidores fornecer um caso reproduzível fornecendo um repositório de exemplo ou fornecer outra maneira de reproduzir o problema.

Obrigado pela resposta rápida!
Isso será difícil porque o repositório atual é privado na minha organização... Avisarei se conseguir :)

Isso continua acontecendo comigo com jest v^24.6.0 e node v10.14.2 . Alguma ideia do porquê?

Recentemente atualizei algumas dependências em um projeto e não tenho nenhum problema, enfrento isso há um mês, mas foi resolvido em versões mais recentes acredito...

Você pode compartilhar as versões que você está usando agora, quando estiver resolvido?

Em segunda-feira, 5 de agosto de 2019 às 12h43 Norman Enmanuel [email protected]
escrevi:

Obrigado pela resposta rápida!
Isso será difícil porque o repositório atual é privado na minha organização...
você sabe se eu conseguir :)

Recentemente atualizei algumas dependências em um projeto e não tenho nenhuma
problema, enfrento isso há um mês, mas fui resolvido em versões mais recentes que
acreditam...

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/facebook/jest/issues/3853?email_source=notifications&email_token=AB6F4PAE3CHUMEBP7IYXRPLQC7Y2DA5CNFSM4DPZ3JSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3RI3PY#issuement-5
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AB6F4PFXDSRHBW5CMTT2DKDQC7Y2DANCNFSM4DPZ3JSA
.

Você pode compartilhar as versões que você está usando agora, quando estiver resolvido?

Certo:

brincadeira

^24.8.0

nó -v

v10.16.0

E estes são alguns scripts npm que eu uso para rodar ambos, e2e, integração, unidade e aceitação:

"scripts": {
  "test": "NODE_ENV=test npm run test:unit && npm run test:integration:both",
  "test:unit": "NODE_ENV=test jest --config test/jest.config.unit.js --detectOpenHandles",
  "test:integration": "NODE_ENV=test MOCK=false jest --config test/jest.config.integration.js --runInBand --detectOpenHandles",
  "test:integration:mock": "NODE_ENV=test MOCK=true jest --config test/jest.config.integration.js --runInBand --detectOpenHandles",
  "test:integration:both": "NODE_ENV=test npm run test:integration:mock -- --coverage; npm run db:migration:test; npm run test:integration -- --coverage;",
  "test:report": "open docs/test/report/index.html",
  "test:report:coverage": "open docs/test/coverage/lcov-report/index.html"
}

Um este é o jest.config:

"use strict";

module.exports = {
  "bail": true,
  "verbose": false,
  "collectCoverage": false,
  "expand": true,
  "testURL": "http://localhost:3000/",
  "coverageDirectory": "./docs/test/coverage",
  "testEnvironment": "node",
  "rootDir": "../",
  "setupFilesAfterEnv": [
    "./test/jest.setup.js"
  ],
  "jest.showCoverageOnLoad": true,
  "watchPathIgnorePatterns": ["node_modules"],
  "transform": {
    "^.+\\.js$": "babel-jest",
    '^.+\\.tsx?$': 'ts-jest',
  },
  "reporters": [
    "default",
    ["./node_modules/jest-html-reporter", {
      "pageTitle": "...",
      "outputPath": "./docs/test/report/index.html",
      "includeFailureMsg": true,
      "sort": "titleAsc",
      "dateFormat": "yyyy-mm-dd HH:MM:ss"
    }]
  ]
};

Espero que ajude.

Vou tentar encontrar um tempo para reproduzir isso então. Até então eu descobri que meus logs são consumidos pelos resultados, como você pode ver abaixo. Antes que FAIL apareça você pode ver meus 2 logs lá. E também vale a pena mencionar que apenas 2 logs são removidos. Se eu adicionar 10 logs um sob o outro, 8 serão mostrados. Acho que é um bom começo :)

@kresli Qual é a barra de status e a saída de tempo que você tem aqui? Quando executo meu conjunto de testes, vejo _RUN HARNESS test-harness/index.js_ e nada mais até que tudo seja executado. Eu então vejo minha mensagem console.log no final e a linha com _RUN HARNESS..._ muda para _APROVEITAR...._

Atualização: ignore, acabou sendo um problema no meu código

Ainda enfrentando isso com o nó v12.16.1, jest 25.5.4, typescript 3.8.3 no MacOS. Tentei as recomendações de usar --runInBand, desabilitar/habilitar verbose, usando --silent=true, não ajudou.