Jest: Masquer la journalisation de la console pour réussir les tests et l'afficher pour les échecs

Vous pouvez écrire un journaliste personnalisé. Cc @aaronabramov

Voici un exemple de nos tests : https://github.com/facebook/jest/blob/master/integration_tests/custom_reporters/reporters/test_reporter.js.

Salut, merci pour les infos utiles.

Cependant, j'ai essayé d'écrire un journaliste personnalisé et j'ai rencontré quelques problèmes :

• Il n'y a pas de moyen simple d'hériter de toutes les fonctionnalités du rapporteur par défaut (sortie de test informative, etc.) et je préfère ne pas tout ré-implémenter à partir de zéro
• Lorsque j'inclus le reporter par défaut dans ma configuration, transmettez --silent dans la CLI (pour que le reporter par défaut masque la journalisation de la console) et ajoutez mon reporter personnalisé à ma configuration, je ne vois pas de moyen simple dans mon reporter personnalisé pour imprimer la journalisation. Il semble qu'en raison de l'option --silent , les classes reporter n'aient plus accès à la console tamponnée.

Pour cette raison, j'aimerais proposer un correctif à Jest qui introduira une valeur de configuration pour afficher la console uniquement en cas d'échec des tests. Envisageriez-vous un tel patch ?

Cela nécessite évidemment des tests et il faudra vérifier une valeur de configuration mais voici l'idée générale (qui fonctionne):

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 +

J'aime vraiment cette idée, mais il y a beaucoup de choses que nous devons considérer

nous devons ajouter des informations sur la sortie cachée

PASS __tests__/my_test.js (hidden output)

nous devrions également le désactiver lors de l'exécution de quelques tests ou d'un seul test (je suppose que l'on ne l'active pratiquement que pour un test complet)

@cpojer avez-vous des idées à ce sujet ?

Je pense que ce comportement est déroutant et je préférerais que Jest soit cohérent dans ce qu'il génère par test, quel que soit l'état.

@cpojer pour moi, c'est déroutant d'essayer de trouver des messages de console relatifs à mon test qui ont échoué :/ Si vous pouvez suggérer de meilleures façons d'y parvenir, faites-le.

En guise de compromis, accepteriez-vous un correctif qui expose DefaultReporter dans jest.js afin que je puisse l'étendre ? Sinon, je devrais copier et coller le monde pour implémenter cette fonctionnalité dans un reporter personnalisé.

Voici à quoi ressemble ma sortie de test:

Je ne peux pas me débarrasser des avertissements à cause de https://github.com/facebook/flow/issues/4673 , et heureusement, il n'y a que quelques messages de journal, mais si je veux ajouter plus de journalisation, ce sera bien pire .

Je suis d' accord avec @miracle2k , lorsque vous recevez de nombreux avertissements et erreurs de dépendances, il est beaucoup plus difficile de trouver des tests ayant échoué. Ce serait bien d'avoir un indicateur que vous pourriez passer qui ne renverrait que la liste des tests échoués.

D'accord, avoir un indicateur pour masquer la sortie de la console pour le test PASS et le laisser pour le test ECHEC serait un excellent ajout pour rendre la sortie du test plus lisible

Je serais d'accord. Je travaille actuellement sur un projet avec un grand groupe de tests et le résultat des tests réussis rend le flux de travail plus difficile lors du débogage.

D'accord sur le drapeau qui masque la sortie de la console pour les tests PASS.

PASS __tests__/my_test.js (hidden output)

Pouvons-nous faire reconsidérer cet ajout par hasard ?

Nous avons maintenant un moyen d'exécuter uniquement des tests qui échouent, ce qui devrait couvrir ce cas d'utilisation. Voir #4886 (disponible dans jest 22)

Nous avons maintenant un moyen d'exécuter uniquement des tests qui échouent, ce qui devrait couvrir ce cas d'utilisation.

Il ne couvre que partiellement le cas. Par exemple, si 5 tests sur 100 échouent dans une suite avec beaucoup de journalisation, vous pouvez réexécuter uniquement les tests ayant échoué pour donner un sens à la sortie de la console. Cependant, si vous masquiez la journalisation pour la réussite des tests depuis le début, vous n'auriez pas eu besoin de réexécuter les tests.

En outre, la réexécution uniquement des tests défaillants présente l'inconvénient de ne pas détecter les nouveaux échecs de test introduits par les modifications de code.

Si l'équipe principale ne souhaite pas implémenter cette fonctionnalité, quelqu'un pourrait-il considérer ma proposition de compromis ? Cette proposition me permettrait d'écrire plus facilement un reporter personnalisé pour implémenter le masquage de console. Je peux faire le patch mais je ne veux pas soumettre de pull request s'il ne sera pas accepté.

@ kumar303 s'il vous plaît envoyez un PR, semble assez

@kumar303 avez-vous fini par soumettre un PR ? J'aimerais avoir ça aussi.

J'ai toujours l'intention d'en soumettre un mais je n'ai pas réussi à trouver du temps entre mes autres priorités de travail. Si quelqu'un d'autre me bat, faites-le moi savoir afin que je puisse vous aider à le tester !

Mon idée était d'exporter DefaultReporter partir de jest.js afin qu'un journaliste personnalisé puisse l'étendre. Je pensais commencer par changer cette ligne en quelque chose comme :

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

Je suis sûr qu'il faudrait plus de réglages après cela.

@kumar303 Comment puis-je ajouter votre code à ma configuration de jest ?

Cela m'intéresse aussi. Suite à l'idée de @kumar303 , j'ai pu écrire un journaliste personnalisé qui étend assez facilement default_reporter (bien que fragile, puisque je l'importe directement à partir de jest-cli/build/reporters/default_reporter ), puis transforme result.console comme je l'entends (dans ce cas, je laisse l'utilisateur définir un niveau de journalisation minimum).

Cela fonctionne bien à une exception près : lors de l'exécution d'un seul test, les messages de la console ne sont pas mis en mémoire tampon. Ceci est mentionné ici : https://github.com/facebook/jest/issues/2080

Ainsi, dans ces scénarios, il n'est pas possible d'influencer la sortie de la console à partir d'un rapporteur personnalisé. Donc, je ne pense pas que la suggestion originale de @thymikee d'utiliser un journaliste personnalisé pour gérer la sortie de la console fonctionne de manière universelle, à moins que nous puissions également avoir un moyen de forcer Jest à toujours mettre en mémoire tampon la sortie de la console.

Heureux d'exposer notre reporter par défaut d'une manière plus propre.

Cela vous dérange d'ouvrir un problème distinct sur la mise en mémoire tampon forcée de console.logs ? Doit être cohérent

Y a-t-il un inconvénient important à avoir une variable de configuration globale comme showLogsForFailedTests: true ? La valeur par défaut ne change rien à la façon dont Jest fonctionne actuellement et la valeur de false rendrait la lecture des tests beaucoup plus agréable.

Ce problème est-il fermé parce que quelque chose a été fait pour le résoudre ou est-il fermé parce que plus de 30 personnes imaginent avoir un problème avec Jest qu'elles n'ont pas réellement ?

garçon, je pensais que c'était à peu près une approche standard pour afficher uniquement le journal des échecs pour plaisanter ... est-ce toujours un problème?

Besoin de ça. Ça perturbe vraiment.

Pour info : nous avons implémenté avec succès l'idée de @kumar303 dans un reporter personnalisé basé sur le reporter par défaut de Jest ici : https://github.com/mozilla/addons-frontend/blob/e1606743d79e779b1902399685f35a90aa6b9ab9/tests/jest-reporters/fingers-crossed. js

• Sans ce journaliste : https://travis-ci.org/mozilla/addons-frontend/jobs/413610593
• Avec ce journaliste : https://travis-ci.org/mozilla/addons-frontend/jobs/413753679

@willdurand J'ai essayé votre journaliste. Je ne suis pas sûr de ce que j'ai pu faire de mal puisque tout ce que j'ai fait a été de sélectionner ce fichier en tant que journaliste. Tout ce qu'il a fait, c'est empêcher cela de s'afficher à la fin des tests :

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

Tous les journaux pendant les tests s'affichaient toujours.

L'avez-vous peut-être exécuté pour un seul test ? Voir mon commentaire précédent et
rapport de bogue associé. Il n'est pas possible de capturer les journaux avec un journaliste
lorsqu'un seul test est exécuté, c'est le véritable point d'achoppement.

Le mercredi 8 août 2018, à 19 h 08, jazoom [email protected] a écrit :

@willdurand https://github.com/willdurand J'ai essayé votre journaliste. je suis
je ne sais pas ce que j'ai pu faire de mal puisque tout ce que j'ai fait a été de sélectionner ce fichier
en tant que journaliste. Tout ce qu'il a fait, c'est empêcher que cela apparaisse à la fin de la
essais :

Suites de tests : 48 réussies, 48 ​​au total
Tests : 78 réussis, 78 au total
Instantanés : 73 réussis, 73 au total

Tous les journaux pendant les tests s'affichaient toujours.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/facebook/jest/issues/4156#issuecomment-411582223 , ou mute
le fil
https://github.com/notifications/unsubscribe-auth/AAi-gO9_uEJPO4xnhkpfGore_hEX81fUks5uO29bgaJpZM4OnBQQ
.

@jamietre Je l'ai exécuté pour exactement la même commande que j'ai utilisée pour le test qui a exécuté 48 suites.

Edit : pour clarifier, j'ai exécuté la même commande deux fois. La seule différence avec le rapporteur personnalisé était qu'il n'imprimait pas ce résumé à la fin :

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

@jazoom le reporter n'aura aucun effet si vous avez verbose: true dans votre configuration. Essayez de régler cela sur false .

@jamietre je suis d'accord. C'est un comportement étrange qu'un seul test ne capture ou n'affiche aucune sortie de console (https://github.com/facebook/jest/issues/6441).

Il n'est pas non plus utile que jest ne regroupe pas la sortie de la console par test (https://github.com/facebook/jest/issues/2080). Un rapporteur personnalisé ne peut afficher que la sortie de la suite (c'est-à-dire un fichier de test), pas un test défaillant spécifique.

@jazoom veille également à redémarrer complètement jest après avoir installé ou modifié le reporter. Cela peut ne pas être évident car jest reconnaîtra les modifications apportées aux autres fichiers source lors de l'exécution (mais pas les reporters).

@ kumar303 il n'est pas défini sur verbeux

Qu'entends-tu par "redémarrer complètement" ? C'est juste un script qui s'exécute.

Qu'entends-tu par "redémarrer complètement" ?

Je voulais dire que si vous êtes en mode montre de plaisanterie, vous devez quitter.

D'accord. Je n'utilise pas le mode montre.

ah oui, en effet. Je n'ai pas remarqué cela, mais pour certaines raisons, Jest n'affiche pas le résumé final en bas, une fois que toutes les suites de tests ont été exécutées.

Je suppose que c'est parce que nous étendons le DefaultReporter et pas le SummaryReporter , peut-être..

@willdurand J'ai essayé votre configuration qui masque avec succès les journaux. Cependant, le terminal n'est plus vidé (logs précédents) et tous les logs s'empilent les uns en dessous des autres.

Remarque : En exportant simplement la classe DefaultReporter , je reviens à la journalisation par défaut mais la pile des journaux également

J'ai joué un peu avec le FingersCrossedReporter de @kumar303 / @willdurand
Cependant, comme d'autres l'ont noté, il n'imprime pas le résumé du test à la fin des tests. C'est parce que (je pense) les paramètres par défaut de Jest utilisent deux reporters - le DefaultReporter et le SummaryReporter.
Maintenant, je ne peux pas importer directement le SummaryReporter dans ma configuration jest car il est exporté par défaut et cela ne semble pas importable. J'ai contourné le problème en le réexportant à partir d'un autre fichier.

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

Configuration de plaisanterie

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

Edit: Après avoir joué un peu avec, je vois que cela se connecte pour l'ensemble du bloc de description, si un seul test échoue cependant.

nous allons corriger la prise en charge de l'exportation par défaut pour jest 25.

tu peux aussi faire

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

Nous pourrions cependant vouloir ajouter des fichiers @jest/reporters/SummaryReporter etc, donc vous n'avez pas besoin du fichier js intermédiaire... Voulez-vous ouvrir une demande de fonctionnalité distincte pour cela ?

Pourquoi cette demande de fonctionnalité est-elle fermée ?
Il semble que de nombreuses personnes trouvent raisonnable d'inclure cette fonctionnalité dans une plaisanterie prête à l'emploi. Au moins comme option de configuration.
Pouvez-vous @kumar303 l' ouvrir à nouveau ?

Pouvez-vous @kumar303 l' ouvrir à nouveau ?

Il h. Non, je n'y ai pas accès. C'était la raison de la fermeture : https://github.com/facebook/jest/issues/4156#issuecomment -324638718 Je reconnais que c'est une fonctionnalité essentielle. Je suis surpris de voir à quel point les développeurs de core jest peuvent vivre sans, mais peut-être qu'ils n'écrivent pas de code avec des bogues, ils n'ont donc pas besoin de journaux.

Veuillez rouvrir. Nous avons besoin de cela aussi.

Pourquoi ce n'est pas encore possible ?

Cela me semble une fonctionnalité évidente. La plupart de nos tests produisent au moins une page de texte de console chacun, c'est incroyablement ennuyeux de devoir les parcourir pour trouver les tests qui ont échoué.

Je ne connais pas d'autre moyen d'enregistrer mon soutien pour ce comportement que de laisser un commentaire. Je sais que 👍 et autres sont moins utiles, donc c'est le mieux que je puisse faire. Merci pour tout de la part de toutes les personnes impliquées ! J'ai suivi tous les fils de discussion et j'attends cela avec impatience chaque fois que les gens auront des cycles pour obtenir aux gens ce qu'ils veulent lol.

Le fait que cette fonctionnalité n'ait pas été implémentée depuis près de trois ans, quand c'est nécessaire, est assez étrange.

Sur la base d'extraits que j'ai trouvés sur Internet, j'ai proposé une configuration globale pour cela; voir https://stackoverflow.com/questions/58936650/javascript-jest-how-to-show-logs-from-test-case-only-when-test-fails/61909588#61909588

Espérons que cela aide quelqu'un.

Vous voudrez peut-être jeter un œil à https://github.com/AtakamaLLC/capio pour une capture asynchrone.

Veuillez le rouvrir et l'implémenter en tant que configuration facultative.
Je le ferais moi-même s'il y avait une chance réaliste de faire accepter un PR.
À mon avis, écrire un journaliste personnalisé pour cette "petite" demande de fonctionnalité serait une surcharge de maintenance insoutenable.

Bien que cette demande de fonctionnalité ne soit ni "propre" ni "cohérente", elle est toujours très demandée par de nombreuses personnes.