Jest: Oculte o registro do console para passar nos testes e mostre-o para falhas

Você pode escrever um repórter personalizado. Cc @aaronabramov

Aqui está um exemplo de nossos testes: https://github.com/facebook/jest/blob/master/integration_tests/custom_reporters/reporters/test_reporter.js.

Oi, obrigado pela informação útil.

No entanto, tentei escrever um repórter personalizado e encontrei alguns empecilhos:

• Não há uma maneira fácil de herdar todas as funcionalidades do relator padrão (resultado de teste informativo, etc) e prefiro não reimplementar tudo do zero
• Quando incluo o relator padrão em minha configuração, passo --silent na CLI (para fazer o relator padrão ocultar o registro do console) e adicionar meu relator personalizado à minha configuração, não vejo uma maneira fácil em meu repórter personalizado para imprimir o registro. Parece que por causa da opção --silent , as classes repórter não têm mais acesso ao console em buffer.

Por causa disso, gostaria de propor um patch para Jest que apresentará um valor de configuração para mostrar o console apenas em testes com falha. Você consideraria tal patch?

Isso obviamente precisa de testes e será necessário verificar se há um valor de configuração, mas aqui está a ideia geral (que está funcionando):

diff --git a/packages/jest-cli/src/reporters/default_reporter.js b/packages/jest-cli/src/reporters/default_reporter.js
index 08d4a9f2..adedbdd3 100644
--- a/packages/jest-cli/src/reporters/default_reporter.js
+++ b/packages/jest-cli/src/reporters/default_reporter.js
@@ -176,7 +176,8 @@ class DefaultReporter extends BaseReporter {
       this.log(getResultHeader(result, config));

       const consoleBuffer = result.console;
-      if (consoleBuffer && consoleBuffer.length) {
+      const testFailed = result.numFailingTests > 0;
+      if (testFailed && consoleBuffer && consoleBuffer.length) {
         this.log(
           '  ' +
             TITLE_BULLET +

na verdade, gosto dessa ideia, mas há muitas coisas que precisamos considerar

precisamos adicionar algumas informações sobre a saída oculta

PASS __tests__/my_test.js (hidden output)

também devemos desabilitá-lo ao executar alguns testes ou um único teste (acho que praticamente só habilitá-lo para uma execução de teste completo)

@cpojer , você tem alguma opinião sobre isso?

Acho que esse comportamento é confuso e prefiro que o Jest seja consistente no que ele produz por teste, independentemente do estado.

@cpojer para mim, é confuso tentar encontrar mensagens de console relacionadas ao meu teste que falhou: / Se você pode sugerir maneiras melhores de fazer isso, faça.

Como um meio-termo, você aceitaria um patch que expõe DefaultReporter em jest.js para que eu possa estendê-lo? Caso contrário, eu teria que copiar e colar o mundo para implementar esse recurso em um reporter personalizado.

Esta é a aparência da minha saída de teste:

Não consigo me livrar dos avisos por causa de https://github.com/facebook/flow/issues/4673 e, felizmente, há apenas algumas mensagens de registro, mas se eu quiser adicionar mais registros, ficará muito pior .

Segundo @ miracle2k , quando você recebe muitos avisos e erros de dependências, fica muito mais difícil encontrar testes que falharam. Seria bom ter um sinalizador que você pudesse passar e que retornasse apenas a lista de testes que falharam.

Concordado, ter um sinalizador para ocultar a saída do console para o teste PASS e deixá-la para o teste FALHA seria uma grande adição para tornar a saída do teste mais legível

Eu concordaria. Atualmente, estou trabalhando em um projeto com um grande grupo de testes e a saída dos testes de aprovação torna o fluxo de trabalho mais difícil durante a depuração.

Acordado no sinalizador que esconde a saída do console para testes PASS.

PASS __tests__/my_test.js (hidden output)

Podemos ter este acréscimo reconsiderado por acaso?

Agora temos uma maneira de executar apenas testes de falha, que devem abranger este caso de uso. Veja # 4886 (disponível em 22 de junho)

Agora temos uma maneira de executar apenas testes de falha, que devem abranger este caso de uso.

Ele cobre apenas parcialmente o caso. Por exemplo, se 5 de 100 testes falharem em um conjunto com muitos registros, você poderá executar novamente apenas os testes com falha para entender a saída do console. No entanto, se você estivesse ocultando o registro para passar nos testes o tempo todo, não teria que executar novamente os testes.

Além disso, a reexecução apenas de testes com falha tem uma desvantagem, pois não detectará nenhuma nova falha de teste introduzida por edições de código.

Se a equipe principal não quiser implementar esse recurso, alguém poderia considerar minha proposta de meio-termo? Essa proposta me permitiria escrever mais facilmente um relator personalizado para implementar o ocultamento de console. Posso fazer o patch, mas não quero enviar uma solicitação de pull se ela não for aceita.

@ kumar303 envie um PR. Parece bastante

@ kumar303 você acabou enviando um PR? Eu gostaria de ter isso também.

Ainda pretendo enviar um, mas não consegui encontrar tempo entre minhas outras prioridades de trabalho. Se mais alguém chegar antes de mim, por favor, me avise para que eu possa ajudar a testá-lo!

Minha ideia era exportar DefaultReporter de jest.js para que um repórter personalizado pudesse estendê-lo. Eu estava pensando em começar mudando esta linha para algo mais parecido com:

const testFailed = result.numFailingTests > 0;
if (testFailed && consoleBuffer && consoleBuffer.length) {
  // Log console output
}

Tenho certeza de que precisaria de mais ajustes depois disso.

@ kumar303 Como posso adicionar seu código à minha configuração de jest?

Também estou interessado nisso. Seguindo a ideia de @ kumar303 , consegui escrever um repórter personalizado que estende default_reporter facilmente (embora frágil, já que estou importando-o diretamente de jest-cli/build/reporters/default_reporter ) e, em seguida, transforma result.console conforme eu vejo o ajuste (neste caso, eu deixo o usuário definir um nível mínimo de log).

Ele funciona bem, exceto por uma coisa - ao executar um único teste, as mensagens do console não são armazenadas em buffer. Isso é mencionado aqui: https://github.com/facebook/jest/issues/2080

Portanto, nesses cenários, não há capacidade de influenciar a saída do console a partir de um relator personalizado. Portanto, não acho que a sugestão original de @thymikee de usar um repórter personalizado para gerenciar a saída do console funcione universalmente, a menos que possamos ter alguma forma de forçar o jest a sempre fazer buffer da saída do console.

Fico feliz em expor nosso repórter padrão de uma maneira mais limpa.

Importa-se de abrir uma questão separada sobre o buffer forçado de console.logs? Deve ser consistente

Existe uma desvantagem significativa em ter uma variável de configuração global como showLogsForFailedTests: true ? O valor padrão não muda nada de como Jest funciona atualmente e o valor de false tornaria a leitura dos testes muito mais agradável.

Este problema foi encerrado porque algo foi feito para corrigi-lo ou foi encerrado porque mais de 30 pessoas estão imaginando que têm um problema com o Jest que não estão realmente tendo?

rapaz, achei que essa fosse uma abordagem padrão para mostrar apenas o log que falhou por brincadeira ... isso ainda é um problema?

Preciso disso. Isso realmente atrapalha.

Para sua informação: implementamos com sucesso a ideia de @ kumar303 em um repórter personalizado com base no repórter padrão de Jest aqui: https://github.com/mozilla/addons-frontend/blob/e1606743d79e779b1902399685f35a90aa6b9ab9/tests/jest-reporters/fingers-crossed. js

• Sem este repórter: https://travis-ci.org/mozilla/addons-frontend/jobs/413610593
• Com este repórter: https://travis-ci.org/mozilla/addons-frontend/jobs/413753679

@willdurand eu tentei seu repórter. Não tenho certeza do que poderia ter feito de errado, pois tudo que fiz foi selecionar aquele arquivo como o relator. Tudo o que fez foi evitar que isso fosse mostrado no final dos testes:

Test Suites: 48 passed, 48 total
Tests:       78 passed, 78 total
Snapshots:   73 passed, 73 total

Todos os logs durante os testes ainda apareceram.

Talvez você o tenha executado apenas para um único teste? Veja meu comentário anterior e
relatório de bug associado. Não é possível capturar logs com um repórter
quando apenas um teste é executado, este é o verdadeiro obstáculo.

Na quarta-feira, 8 de agosto de 2018, 19h08 jazoom [email protected] escreveu:

@willdurand https://github.com/willdurand Eu tentei seu repórter. Eu estou
não tenho certeza do que poderia ter feito de errado, pois tudo que fiz foi selecionar aquele arquivo
como o repórter. Tudo o que fez foi evitar que isso fosse mostrado no final do
testes:

Suítes de teste: 48 aprovadas, 48 ​​no total
Testes: 78 aprovados, 78 no total
Instantâneos: 73 aprovadas, 73 no total

Todos os logs durante os testes ainda apareceram.

-
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/4156#issuecomment-411582223 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAi-gO9_uEJPO4xnhkpfGore_hEX81fUks5uO29bgaJpZM4OnBQQ
.

@jamietre Eu executei exatamente o mesmo comando que usei para o teste que executou 48 suítes.

Edit: para esclarecer, executei o mesmo comando duas vezes. A única diferença com o repórter personalizado era que não imprimia este resumo no final:

Test Suites: 48 passed, 48 total
Tests:       78 passed, 78 total
Snapshots:   73 passed, 73 total

@jazoom, o repórter não terá nenhum efeito se você tiver verbose: true em sua configuração. Tente definir isso para false .

@jamietre eu concordo. É um comportamento estranho que um único teste executado não capture ou exiba qualquer saída do console (https://github.com/facebook/jest/issues/6441).

Também não é útil como o jest não agrupa a saída do console por teste (https://github.com/facebook/jest/issues/2080). Um relator personalizado pode mostrar apenas a saída do conjunto (ou seja, um arquivo de teste), não um teste específico com falha.

@jazoom também certifique-se de reiniciar completamente o jest após instalar ou alterar o repórter. Isso pode não ser óbvio, pois o jest reconhecerá as alterações em outros arquivos de origem durante a execução (mas não os repórteres).

@ kumar303 não está definido como detalhado

O que você quer dizer com "reiniciar completamente"? É apenas um script que roda.

O que você quer dizer com "reiniciar completamente"?

Eu quis dizer que se você está no modo de relógio de brincadeira, você precisa sair.

OK. Eu não uso o modo relógio.

ah sim, de fato. Eu não percebi isso, mas por alguns motivos, Jest não mostra o resumo final na parte inferior, uma vez que todos os conjuntos de testes foram executados.

Suponho que seja porque estendemos DefaultReporter e não SummaryReporter , talvez ..

@willdurand eu tentei sua configuração que esconde os logs com sucesso. No entanto, o terminal não é mais limpo (logs anteriores) e todos os logs empilham os que estão abaixo dos outros.

Observação: apenas exportando a classe DefaultReporter , volto para o registro padrão, mas também para a pilha de registros

Eu brinquei um pouco com o FingersCrossedReporter de @ kumar303 / @willdurand
No entanto, como alguns outros observaram, ele não imprime o resumo do teste no final dos testes. Isso ocorre porque (eu acho) as configurações padrão do Jest usam dois repórteres - o DefaultReporter e o SummaryReporter.
Agora não consigo importar diretamente o SummaryReporter em minha configuração jest, pois ele é exportado por padrão e não parece importável. Eu resolvi isso reexportando-o de outro arquivo.

//summary-reporter.js
const SummaryReporter = require('@jest/reporters/build/summary_reporter')
  .default;
module.exports = SummaryReporter;

//log-on-fail-reporter.js
Content: https://gist.github.com/GeeWee/71db0d9911b4a087e4b2486386168b05
Same as reporter above, but with updated import paths for the new jest structure

Configuração de Jest

    "reporters": [
      "<rootDir>/src/test-reporters/log-on-fail-reporter.js",
      "<rootDir>/src/test-reporters/summary-reporter.js"
    ],

Editar: depois de brincar um pouco, vejo que isso registra todo o bloco de descrição, se um único teste falhar.

vamos consertar o suporte para exportação padrão para o jest 25.

você também pode fazer

//summary-reporter.js
const {SummaryReporter} = require('@jest/reporters')
module.exports = SummaryReporter;

Podemos querer adicionar arquivos @jest/reporters/SummaryReporter etc, então você não precisa do arquivo js intermediário ... Quer abrir uma solicitação de recurso separada para isso?

Por que esta solicitação de recurso está fechada?
Parece que muitas pessoas acham razoável ter esse recurso incluído em piadas prontas para usar. Pelo menos como opção de configuração.
Você pode @ kumar303 abri-lo novamente?

Você pode @ kumar303 abri-lo novamente?

Heh. Não, eu não tenho acesso. Esta foi a justificativa para o fechamento: https://github.com/facebook/jest/issues/4156#issuecomment -324638718 Concordo que é um recurso essencial. Estou surpreso como os principais desenvolvedores de jest podem viver sem ele, mas talvez eles não escrevam código com bugs, portanto, não precisam de logs.

Abra novamente. Precisamos disso também.

Por que isso ainda não é possível?

Parece uma funcionalidade óbvia para mim. A maioria dos nossos testes produz pelo menos uma página de texto do console cada, é incrivelmente chato ter que vasculhar isso para encontrar os testes que falharam

Não conheço outra maneira de registrar meu apoio a esse comportamento do que deixando um comentário. Eu sei 👍 e outros semelhantes são menos úteis, então isso é o melhor que sinto que posso fazer. Obrigado por tudo de todos os envolvidos! Eu segui todos os tópicos e estou ansioso por isso, sempre que as pessoas têm ciclos para conseguir o que elas querem lol.

O que esse recurso não é implementado há quase três anos, quando é necessário, é meio estranho.

Com base em trechos que encontrei na Internet, criei uma configuração global para isso; consulte https://stackoverflow.com/questions/58936650/javascript-jest-how-to-show-logs-from-test-case-only-when-test-fails/61909588#61909588

Espero que isso ajude alguém.

Talvez você queira dar uma olhada em https://github.com/AtakamaLLC/capio para captura assíncrona.

Abra novamente e implemente-o como uma configuração opcional.
Eu mesmo faria isso se houvesse uma chance real de conseguir a aceitação de um RP.
Na minha opinião, escrever um relator personalizado para essa "minúscula" solicitação de recurso seria uma sobrecarga de manutenção insustentável.

Embora essa solicitação de recurso não seja "limpa" nem "consistente", ainda é altamente necessária para muitas pessoas.