Jest: console.log ne s'affiche pas lors de l'exécution des tests

Je viens de tester ceci en utilisant repl.it : https://repl.it/EwfT/0

La bonne nouvelle est que cela fonctionne comme prévu et les sorties console.log. J'ai essayé de rétrograder ma version jest à 17.0.3, je voyais toujours les mêmes problèmes. Installé nvm pour tester avec le nœud v6.9.2, et hourra console.log fonctionne avec jsdom, donc je suppose que le problème est lié au nœud v7.

Merci d'avoir signalé cela, mais c'est un doublon de #2166 et cela se produit également sur le nœud 6.

@thymikee Comment est-ce un doublon de #2166 ? Dans ce scénario, console.log ne génère rien du tout. J'ai ce problème avec Node v4. Ce qui est frustrant, c'est que cela fonctionnait bien plus tôt dans la journée et qu'avec 0 modifications apportées à mon environnement, je ne reçois plus console.log sorties

@thisissami, il semble que votre test ou votre code ne soit pas en cours d'exécution. La suite de tests de Jest passe sur les nœuds 4 et 6, ce qui garantit que l'impression de la console fonctionne correctement et nous travaillons sur un correctif pour la version 7.3.

@cpojer - Mes tests réussissent / échouent correctement - seuls les messages console.log ne s'affichent pas. J'ai découvert cela en essayant de comprendre quelles sont les propriétés d'un objet particulier en le console.log , et en ne voyant aucune sortie. J'ai ajouté de nombreuses instructions console.log et aucune n'apparaît dans mon terminal maintenant. =/ Je reviens actuellement à Jest v17 pour voir si cela change quelque chose.

Si cela fonctionnait plus tôt dans la journée pour vous et ne fonctionne plus, vous devez avoir fait une mise à jour ou cassé quelque chose vous-même. Nous n'avons pas publié de version de Jest depuis deux semaines.

ok donc la seule chose qui a changé dans mon code de test est que j'ai ajouté un commentaire multiligne après le code qui est censé s'exécuter (comme référence pour moi-même). Je vais voir si enlever ça fait une différence.

@cpojer Je ne sais pas quoi dire, je ne vois rien de mal dans mon code de test mais rien n'est sorti sur 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);
  });
});

Le test échoue, comme prévu, donc je sais que cela fonctionne. Ma config dans package.json est vraiment simple, uniquement :

  "jest": {
    "collectCoverageFrom": [
      "src/*.jsx"
    ]
  }

Jest a fonctionné tout à fait normalement, sans drapeaux supplémentaires attachés. Même problème avec Jest v17 & 18.

Je n'ai modifié aucun fichier autre que celui-ci de toute l'après-midi. Je viens juste de comprendre comment fonctionne enzyme en sortant diverses choses sur stdout , et après avoir commencé à ajouter quelques expects , le console.logs s'est arrêté travailler quand j'en avais à nouveau besoin, et maintenant ils ne fonctionnent plus du tout - peu importe ce que j'ai dans le test. Je n'ai rien changé non plus dans mon environnement (au-delà de la rétrogradation en v17), ce qui est certainement déroutant.

Il semble que vous ayez mis à jour le nœud 7.3. Nous avons quelques correctifs pour cela. Veuillez noter que cet outil de suivi des problèmes n'est pas un forum d'aide ; utilisez stackoverflow pour les questions :)

J'utilise le nœud v4.4.7, et en ce qui me concerne, rien ne s'affiche sur stdout lors de l'utilisation de console.log est un problème. Je n'essaie pas d'obtenir de l'aide pour le codage, je signale ce qui semble être un bogue pour moi. La seule autre chose qui a changé est que j'avais plusieurs fichiers de test en cours d'exécution auparavant, et maintenant un seul. laissez-moi voir si la réactivation des autres tests fait réapparaître les sorties console.log .

@cpojer Assez certain que vous avez un bug ici.

Exécuter 3 tests (comme dans 3 fichiers différents avec .test.js , 2 de ces fichiers étant des exemples de vos tutoriels) fonctionne sans problème. Mon test (copié ci-dessus) rend tous les console.logs.

Le fait de n'avoir qu'un seul test (AKA me renommant .test.js en .teast.js sur 2 des fichiers) n'entraîne aucun rendu des sorties console.log.

Je vais continuer à exécuter un deuxième test arbitraire pour voir la sortie dont j'ai besoin, donc je suis bon pour mes propres besoins personnels - mais cela devrait être résolu imo, en supposant qu'il soit reproductible ailleurs.

La suite de tests de Jest teste ce comportement sur les nœuds 4, 6 et 7.3. Cela fonctionne pour 4 et 6 mais a été cassé en 7.3. Je corrige cela pour le nœud 7.3 et je publierai sous peu une nouvelle version de Jest : https://github.com/facebook/jest/pull/2464

Si la propre suite de tests de Jest utilisant le nœud 4 échoue pour vous, alors quelque chose ne va probablement pas avec votre configuration.

Clonage du référentiel et essai maintenant.

Tout s'est bien passé sauf ces 3 tests. Je ne sais pas quelles implications cela pourrait avoir. Vous avez toutes les informations sur les erreurs liées à console.log que j'ai, ainsi que l'image ci-dessous. Si ce n'est pas un bug en plaisantant, alors qu'il en soit ainsi. Cela me semble étrange cependant que ne rien faire d'autre que suivre les guides entraînerait un scénario où je ne peux pas voir mes journaux lorsque je n'exécute qu'un seul fichier de test.

Ceux-ci indiquent simplement que Mercurial (hg) n'est pas installé, sans rapport avec votre problème. Il semble que la suite de tests passe pour vous et comme dit ; nous testons explicitement le comportement de journalisation dans la suite de tests, il doit donc y avoir un problème avec votre code ou votre configuration.

Ok cool - merci pour vos commentaires. Avez-vous une idée de ce qui pourrait le faire fonctionner lorsqu'il y a plusieurs fichiers mais pas lorsqu'il n'y en a qu'un ? S'il n'y a pas d'évidence "oh, cela provoque parfois un problème comme celui-là" qui vous vient à l'esprit - pas de soucis, je vais juste m'assurer qu'il y a toujours au moins 2 fichiers en cours d'exécution. :)

Je rencontre le même problème, console.log ne s'affiche pas pour moi maintenant (et c'était il y a environ une heure auparavant). J'utilise le nœud 6.9.1 et j'active également l'indicateur --forceExit. Lorsque je n'ai pas activé cet indicateur, la sortie console.log apparaît.

Cependant, j'ai un autre script de test qui utilise l'indicateur --forceExit et console.log apparaît, donc je ne peux pas dire que l'indicateur --forceExit est à l'origine de ce comportement.

Comme @thisissami le fait, je rencontre le problème de journalisation uniquement lorsque j'essaie de tester un seul fichier.

J'avais le même problème, mais j'ai découvert que cela était dû à l'exécution de jest via jest-cli (jest.runCLI) dans gulpfile.js et qu'il avalait la sortie de console.log. Si je lance directement jest, je vois la sortie de la console.

Je constate maintenant un comportement génial, que je ne peux pas encore isoler dans un cas de test simple, sinon je déposerais un nouveau problème.

1) Jest fait un test
2) Jest affiche les instructions console.log (ne clignote pas ici)
3) Jest fait défiler un nombre arbitraire de lignes, qui couvre parfois toutes les lignes console.log, parfois certaines et parfois toutes.
4) Jest exécute le test suivant (les lignes console.log du test précédent disparaissent).

blague v18.1.0

Comme je ne peux pas isoler cela dans un test simple, je suppose que cela a quelque chose à voir avec l'exécution d'un test asynchrone plus complexe.

J'ai le même problème, je me demande si la sortie écrase une autre sortie. Parfois, je vois quelque chose comme ça :

C'est comme si un processus avait généré une erreur (types d'accessoires ayant échoué), mais elle est simplement écrite directement par les journaux de sortie de test.

Suite:

Et parfois, si je Ctrl + c pendant que les tests sont en cours, je verrai les journaux de la console que je ne verrais pas si je laisse les tests se terminer.

Versions
Blague : 17.0.1
Nœud : 6.6.0
MNP : 3.10.3
macOS : 10.12.2
Terminal : 2.7.1 (et aussi dans iTerm2 3.0.13)
Script (en package.json ): jest /src/main/js --watch ou jest /src/main/js --coverage ou jest --watch --onlyChanged ont tous le même comportement.

@davidgilbertson est-ce que cela se produit sur la v18.1 ?

J'ai essayé 18.1.0 et cela semble encore plus buggé. Et je vois toujours des choses comme ça :

Je ne peux pas choisir de modèle en particulier, mais certaines choses se sont produites (j'ai un console.warn('----------------') dans l'un de mes composants.)

• Si je fais défiler un peu vers le haut lorsque je lance les tests, je vois le journal. Si je fais défiler la fenêtre du terminal pendant que les tests se déroulent (afin qu'il commence à défiler automatiquement), une fois le test terminé, je fais défiler vers le haut et la ligne console.warn a disparu (vraisemblablement écrasée).
• Si je lance les tests et que j'appuie tout de suite sur ctrl + c , je vois des journaux de la console. Mais si je fais de même et que je n'interromps pas, ces journaux de console ne sont pas visibles.
• Lorsque j'exécute jest /src/main/js --watch une fois, puis que j'appuie sur a pour l'exécuter à nouveau, il récupère de nombreux tests hérités dans un répertoire src/main/assets/legacy - ne correspondant pas au glob.
• Idem que ci-dessus si je viens de lancer jest --watch (tous mes tests se terminent par .test.js ou .test.jsx ). Donc, appuyer sur 'a' en mode montre semble aller chercher partout, y compris un vieux test de jasmin appelé src/test/js/spec/categoryselector/spec.js . Frapper Enter semble faire ce que j'attends.

Se pourrait-il que toutes les erreurs générées par les accessoires manquants soient à l'origine de ce problème ? Je dois conserver ctrl+c la sortie pour essayer de détecter ces erreurs avant qu'elles ne soient écrasées.

Ne fonctionne pas pour moi non plus (jest 19.0.1, nœud 5.12). Fait intéressant, cela fonctionne sur un autre projet avec la même configuration. Je ne sais pas comment déboguer les tests Jest, donc pouvoir voir certains messages de la console serait assez important, je pense.

Avez-vous essayé d'utiliser le drapeau jest --runInBand pour voir si cela le résout en exécutant des tests en série ? Quelqu'un m'en a parlé, mais n'a pas eu l'occasion de le tester.

L'indicateur bail empêche l'impression des journaux de la console.

J'essaierai. Ce qui est un peu déconcertant, c'est que dans le même projet, certaines instructions de journal de la console sont affichées sur la console, d'autres non. Malheureusement, ceux que j'ai essayé d'ajouter là où un scénario de test échoue n'obtiennent pas de sortie (j'ai essayé d'ajouter partout dans le scénario de test, dans l'unité testée, etc. en vain). Je ne pense donc pas que cela puisse être dû à un indicateur, car le comportement n'est pas concis. C'est un projet natif de réaction, suivant la mise en page standard d'ailleurs.

Rien de tout cela ne semble aider. L'indicateur --bail arrête simplement l'exécution d'autres tests (le test incriminé est le dernier de toute façon dans mon cas), et --runInBands ne semble pas avoir de différence observable. Jest exécute les fichiers mis à jour d'ailleurs, donc si j'insère une instruction console.log, la trace de la pile d'erreurs affiche l'erreur provenant du numéro de ligne mis à jour. C'est juste que le journal de la console ne se produit pas. Puisqu'il est difficile/impossible de déboguer ces tests dans un navigateur (veuillez me corriger si ce n'est pas le cas), console.log est absolument vital pour résoudre certains problèmes dans les tests.

Il semble que ce cas de test n'ait pas été exécuté en fait. Il y avait une TypeError (accéder à une propriété sur un indéfini). Ce qui m'induit en erreur, c'est que j'ai en fait vu la trace de la pile sur la console, ce qui suggère en quelque sorte qu'elle est en cours d'exécution. Donc, voir la trace mais ne pas voir le message de journal n'a pas tout à fait fonctionné :) Est-ce que quelqu'un sait pourquoi c'est fait de cette façon, donc si un test échoue avec une erreur d'exécution, les journaux ne sont pas générés comme il semble ? (Juste pour être clair, je veux dire les journaux qui se sont produits jusqu'au point d'erreur, je ne veux évidemment pas dire les journaux après l'erreur :))

Dans mon environnement, j'avais verbose: true défini dans les options de plaisanterie dans package.json . Changer cela en false (ou le supprimer) a résolu le problème pour moi. Tous mes journaux de console s'affichent maintenant.

C'est en 18.1.

Pour toute autre personne rencontrant ce problème, vérifiez toutes les dépendances récemment ajoutées. J'ai commencé à rencontrer des problèmes après avoir ajouté mock-browser pour tenter de se moquer des objets du navigateur. Apparemment, il remplace global par son propre objet.

package.json (configuration 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
Commenter les bits mock-browser ...

// 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 fonctionne très bien.

Pourquoi ce problème est-il clos ? Clairement pas un doublon de #2166

Je vais ajouter mon 0,02 $ parce que je viens de tomber dessus.

Publier:

• J'utilise jest --watch --verbose (v19.0.2)
• Certaines déclarations (mais pas toutes !) console.log n'apparaissent ni lors du test, ni dans le résumé
• Dans mon cas, je peux l'isoler dans un appel _.reduce : toutes les instructions console.log à l'intérieur de ce bloc ne sont console.log dehors du bloc reduce sont affichées . J'ai vérifié par d'autres moyens (couverture, résultats des tests) que le corps du réducteur est bien appelé. C'est étrange puisque je ne fais rien d'async/promis basé sur cette partie du code, je ne peux pas comprendre pourquoi l'appel de réduction affecterait quoi que ce soit.
• Si j'invoque jest avec --runInBand , je vois toutes les instructions console.log .
• Contrairement à la plupart des rapports précédents, j'utilise "testEnvironment": "node" , pas jsdom

Les commentaires suivants semblent liés à mon problème:

https://github.com/facebook/jest/issues/2441#issuecomment-273643521
https://github.com/facebook/jest/issues/2441#issuecomment-278202180

Il est assez rapide, mais il ne semble que les console.logs sont en fait en cours d' élaboration à l'écran, puis écrasées.

Je viens de confirmer avec une vidéo que le console.log est en fait attiré à l'écran pendant environ 0,2 s avant d'être dessiné.

Exécuter --watch sans --verbose semble résoudre ce problème.

J'ai passé 10 minutes à essayer d'obtenir un cas de reproduction isolé, mais je n'arrive pas à le faire. Cela ne se manifeste probablement qu'avec de grandes (enfin, > 1) suites de tests.

Vous pouvez voir le comportement ici :

• Avant console.log
  

• console.log - affiché pendant une fraction de seconde (<0.2s)
  

• Une fois que console.log est peint
  

Ce problème est vraiment nul, perdant beaucoup de temps sur ce problème et rien ne semble fonctionner. J'ai choisi blague parce que je pensais que les ingénieurs de Facebook avaient une suite de tests décente et maintenant ça...

C'est pourquoi je n'aime pas Jest. Peu importe ce que vous faites, ils effaceront votre console et refuseront d'afficher les instructions de la console, puis ils apparaîtront de manière aléatoire, jusqu'à ce que vous ayez une erreur que vous devez corriger, auquel cas ils feront de leur mieux pour masquer chaque instruction log afin que vous ne puissiez pas le réparer.

Pourquoi n'ARRÊTEZ-vous pas simplement d'essayer de cacher la sortie de la console aux développeurs ? Si je veux des roues d'entraînement, j'utiliserai Angular 1 !

C'est assez agressif @halis. Nous faisons cela parce que Jest parallélise les tests et de nombreux tests peuvent se connecter au terminal en même temps, ce qui signifie que la sortie de Jest devient inutile. En fait, nous faisions cela. Si vous utilisez --verbose , nous ne mettons rien en mémoire tampon et écrivons directement dans la console.

Si cela ne fonctionne pas pour vous, vous pouvez peut-être nous aider en envoyant un PR à Jest et en améliorant ce comportement.

Je suis désolé, j'ai passé une très mauvaise journée vendredi et j'étais frustré. Aucune raison de s'en prendre à vous, vous essayez juste d'aider.

J'ai trouvé l'indicateur --verbose vendredi, ce qui m'a donné suffisamment de résultats pour résoudre mes problèmes.

Encore une fois, désolé d'avoir été si con à ce sujet.

C'est génial. Ne laissez pas les outils JavaScript gâcher vos vendredis 😀

des nouvelles à ce sujet? comment afficher console.log ?

comportement très intéressant, après m'être cogné la tête plusieurs fois (plus comme plusieurs fois), j'ai compris que --verbose est en effet le coupable de ne pas avoir imprimé console.log.
Ma meilleure solution était de créer un autre script dans package.json qui n'a pas d'indicateur détaillé quand je veux que certains msg soient imprimés dans ma console. J'apprécierais vraiment que vous résolviez ça bientôt

Ce problème est en effet assez ennuyeux car il rend difficile/impossible le débogage des tests à l'aide de console.log (je sais... old school mais toujours pratique).
Pour moi, utiliser les options --runInBand fait apparaître mes instructions de journal.

EDIT : je suis à peu près sûr que cela est lié à la façon dont le résultat est affiché à l'écran... Une autre option serait de laisser le développeur choisir un journaliste comme le fait moka.

C'est pire que de ne pas afficher les journaux :

Si j'ai une forme d'erreur dans un test asynchrone, non seulement je ne vois pas les messages de journal, mais les erreurs expect sont également masquées et les exceptions sont avalées.

test('async', (done) => { setTimeout((() => { expect(1).toEqual(2); throw new Error(); done(); }), 1000); });

Nulle part mon test expect n'est affiché.

````
Délai d'expiration - Le rappel asynchrone n'a pas été invoqué dans le délai d'expiration spécifié par 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)

````

Ni runInBand ni verbose:false aide.

J'ai une configuration trivialement simple ( babel-jest ).

@richburdon pour les tests asynchrones utilisant le rappel done vous devez couvrir les cas d'échec avec done.fail()

@thymikee merci pour la réponse rapide. je ne sais pas ce que tu veux dire par contre. pouvez-vous modifier mon test et/ou me diriger vers docs. Merci beaucoup.

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

Je comprends que ce n'est pas idéal, mais c'est ainsi que cela fonctionne actuellement. Il convient de noter que ce n'est pas un problème, lorsque la fonction testée renvoie un Promise . Il y a quelques problèmes affectés par ce comportement, tels que https://github.com/facebook/jest/issues/2136 ou https://github.com/facebook/jest/issues/2059. Si vous avez une idée sur la façon de l'améliorer, nous serions ravis d'examiner un PR et de le réaliser.

Mais ce n'est pas un sujet pertinent pour en discuter, vous pouvez poster vos idées ailleurs.

@thymikee , mon exemple n'était pas bon car setTimeout a des problèmes liés aux promesses qui n'ont rien à voir avec la plaisanterie...

Il convient de noter que ce n'est pas un problème, lorsque la fonction testée renvoie une promesse.

je ne vois pas ça :

````
test('async', (fait) => {
fonction foo() {
return Promise.resolve(1);
}

foo().then(valeur => {
expect(value).toEqual(2); // Jamais signalé ; juste les temps morts.
Fini();
});
});
````

Il n'est pas évident que le code de test intercepte les exceptions pour les appels expect (c'est-à-dire, une partie du framework de test lui-même). Cela semble assez alambiqué?

Donc, juste pour être clair, je devrais envelopper TOUS les tests qui impliquent toutes les fonctions testées qui renvoient des promesses avec un bloc catch -- pour intercepter les appels expect , qui autrement : a) expireront ; b) ne pas signaler l'erreur.

A moins que je ne fasse une autre erreur :

une). Peut-être documenter cela (https://facebook.github.io/jest/docs/asynchronous.html#content) ?

b). Pourquoi ne pas enregistrer l'erreur ? et/ou avez-vous une option pour quitter ?

Passage à https://github.com/facebook/jest/issues/3576

J'ai le même problème avec console.log.
Cela fonctionnait bien dans la v19 et j'ai pu voir la sortie dans la console.
Après la mise à niveau vers la v20.0.3, la sortie a disparu.
J'ai essayé d'ajouter --runInBand ou --verbose , mais cela n'a pas aidé.

Mettez à niveau vers la dernière version de nodejs, s'il vous plaît. C'est un problème connu dans le nœud ~7.3.

@thymikee Vont -ils donc résoudre ce problème ? J'ai tout essayé sous le soleil. Toujours pas de logs de la console. J'utilise le préprocesseur dactylographié et fourni par jest. J'utilisais ts-jest et leur préprocesseur fonctionnait. Est-il possible que cela ait quelque chose à voir avec le préprocesseur ?

@cpojer @lsentkiewicz Doit-on ouvrir un nouveau numéro puisque c'est un nouveau numéro sur une nouvelle version ?

Comme @cpojer l'a mentionné, l'utilisation de la dernière version de node résout le problème.

@marcusjwhelan
Fonctionne pour moi sur v7.10.0

Je vois toujours la sortie de la console être avalée lors de l'utilisation de jest --bail .

@cpojer ne fonctionne pas sur v8.0.0

Ne fonctionne pas sur le nœud 8.0.0

J'ai l'impression que c'est un mauvais bug si vous devez être sur une certaine version pour que cela fonctionne. Que se passe-t-il si votre système s'exécute à 6.0 et qu'il ne fonctionne pas dans 7.0 en raison de certains changements de nodejs. La plaisanterie ne devrait-elle pas fonctionner au moins sur les versions modernes de Node ? au moins 5 ans d'assistance ? @cpojer @taion

Il s'agit d'un bogue dans le nœud 7.3 uniquement. Ils ont fusionné un mauvais changement et l'ont annulé pour 7,4 ou 7,5.

Les gens me disent que cela ne fonctionne pas sur le nœud 8, mais nous avons un test pour ce comportement et il réussit. Si les gens souhaitent créer une reproduction appropriée avec Jest 20 et le nœud 8, veuillez créer un problème pour cela.

@cpojer Je ne vois aucune sortie console.log avec cette configuration (macOS):

$ node --version
v7.4.0

Des dossiers

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

Sortir

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

Test JS unique :

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

Test TS unique :

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

Ayant ce même problème avec le nœud v8.1.2. J'ai également essayé le nœud v7.10.0 et cela n'a pas fonctionné non plus

En travaillant sur un projet React, j'ai essayé Jest car avec Jasmine, c'est une quête totale pour tester les appels HTTP avec whatwg-fetch , l'exécution de Node.js et la transpilation Babel. Mais quand j'ai vu qu'en ce moment avec Jest vous ne pouvez pas imprimer sur la console, c'était interdit d'utiliser ce framework. Avoir le problème avec Node.js 7.10 et Jest 20.0.4.

Enfin, j'ai pu définir tout l'environnement de test avec l'exécution de Jasmine et Node.js en déclarant xmlhttprequest sur la portée globale et en utilisant nock comme faux serveur.

Les bogues peuvent être très difficiles à détecter et à corriger. Mais celui-ci est un P0 signalé il y a 6 mois qui empêchera quiconque de considérer sérieusement Jest comme cadre de test pour tout projet React.

J'avais le même problème que dans les captures d'écran de @davidgilbertson (résultats des tests écrasant console.log) sur Jest 19.0.2 et Node 7.10.0 lors de l'exécution de jest --verbose . Ce qui m'a aidé : lors de l'utilisation de jest --verbose --runInBand cela a fonctionné correctement (premier résultat de test, puis tout console.log).

@cpojer @thymikee pouvez-vous s'il vous plaît rouvrir ce problème afin qu'il retienne l'attention ?

@iffy , pouvez-vous s'il vous plaît créer un problème séparé avec votre repro ? Je vais essayer de le trier et voir ce qui ne va pas.
BTW rien en dessous de l'échec attendu ne sera jamais appelé, car attendu jette.

@thymikee fait (bien que je sois déjà passé au moka - donc pas de soucis pour le tri)

J'ai eu ce problème aussi, et même après avoir lu tout ce fil et tout essayé, je n'arrive pas à résoudre le problème. Mon test est très simple, car je viens d'implémenter jest dans mon application, et même ainsi, console.log ne s'affiche pas.

Ensuite, j'ai essayé d'utiliser winston pour me connecter à un fichier de sortie et cela a fonctionné. Ensuite, j'ai essayé d'utiliser winston pour me connecter à la console et, devinez quoi, cela a fonctionné !

Alors je vous suggère de faire de même. Vérifiez mon fichier 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;

Les fichiers de tests utilisent simplement :

let log = require('./logger.js');
log.debug('some log here!');

Winston fonctionne car il utilise process.stdout.write qui contourne ce bogue dans Jest. J'ai fini par créer mon propre console.log en utilisant le module util node.

@eranimo @Daymannovaes regarde le bug #3853

Ce commentaire dit que cela fonctionne sur 8.1.2 mais j'ai essayé et je n'ai pas réussi à le faire fonctionner. Je suis déjà passé au moka car c'était un assez mauvais bug.

Ce bug sera-t-il corrigé dans la prochaine version ? Aussi, où puis-je trouver quand c'est?

Je ne peux pas mettre à niveau vers la dernière version du nœud (pas une option), donc ce n'est pas une solution. Je pourrais créer mon propre utilitaire de journalisation avec lequel je peux jouer. J'envisage de convertir en moka, mais cela dépend du déroulement de mon expérience logger util.

Veuillez corriger dès que possible, les journaux de la console sont extrêmement utiles pour écrire mes tests.

J'ai temporairement rétrogradé à 19.0.2 et cela fonctionne.

J'ai eu le même problème et je viens de le tester avec la dernière version de node. Ça fonctionne maintenant. :100:

Cela fonctionne également de ma part après le passage de Node.js v7.10 à v8.1.

corrigé pour moi lors de la mise à jour du nœud de 7.4.0 -> 8.2.1

Obtenir ceci sur le nœud v8.4.0 et Jest 21.0.0-beta.1.

Lors de l'exécution d'un seul cas de test avec test.only , la sortie console.log ne s'affiche pas.

Mais si je supprime --testPathPattern file et que j'exécute tous les tests, la sortie s'affiche.

De plus, si j'ajoute await Promise.delay(100) comme dernière étape du test, la sortie s'affiche.

désolé pour ce commentaire, mais c'est un moyen d'amener Jest sur console.log en temps réel plutôt qu'après la réussite ou l'échec d'un test. mon test utilise une boucle while. J'essayais d'enregistrer des valeurs pendant que la boucle était en cours d'exécution ?

@nharrisanalyst utilise le --verbose

merci pour la réponse, mais j'utilise ce drapeau et uniquement console.log() après qu'un test a réussi ou échoué. donc si ma boucle while reste bloquée, je ne peux pas la déboguer avec console.log lors du test, car le test ne réussit ni n'échoue, il reste simplement bloqué dans une boucle.

Jest semble manger n'importe quelle console que je fais dans un setupFiles , setupTestFrameworkScriptFile , ou beforeAll , ce qui rend impossible l'écriture de scripts de configuration de test qui demandent l'entrée de l'utilisateur et valident la commande drapeaux de ligne. Se passe avec ou sans "verbose": true

Partage de mes observations sur console.log() ne s'affichant pas lors de l'exécution de tests avec Jest.

La condition préalable à cela est d'exécuter Jest avec le drapeau --verbose .

Si vous exécutez des tests avec plusieurs fichiers de test , la sortie de console.log() n'est pas visible (la plupart du temps).
Si Jest exécute des tests à partir d' un seul fichier de test , console.log() fonctionne comme prévu.

Vous pouvez contourner ce problème en :

• Exécutez les tests Jest à partir d'un seul fichier. Oui... pas du tout réaliste, alors voyez l'option suivante.
• Utilisez le drapeau --maxWorkers=1 . Quelque part, cela fonctionne bien pour moi. Ma conjecture (*) est ... Jest s'exécute dans le même processus et il n'est pas nécessaire de mettre en mémoire tampon stdout de chaque processus pour les rediriger vers le processus principal.

Si ma supposition (*) est un comportement attendu, je suggère de mettre à jour la documentation pour l'indiquer clairement afin d'éviter que les développeurs ne perdent du temps à essayer de comprendre "pourquoi mon console.log() ne s'affiche pas... parfois".

OK Donc c'est toujours un problème pour certaines personnes, dont moi-même aujourd'hui. J'imagine que ça va continuer à être une chose.

D'après mes tests, Jest quitte le processus avant de sortir les journaux, ce qui signifie qu'il semble que les journaux sont en train d'être avalés.

Pour moi, j'ai défini verbose: true et bail: false dans ma configuration de plaisanterie. Jest continuera jusqu'à ce que tous les tests soient exécutés et affichera toutes les erreurs et tous les journaux. C'est favorable. J'ai également exécuté --runInBand , ce qui revient à définir --maxWorkers=1 .

La plus grande aide a été bail: false car cela a permis à tous les tests de s'exécuter jusqu'à la fin. Il s'est toujours terminé avec le code 1 mais je peux à nouveau voir tous les journaux.

Exécuter Jest v19.0.2 avec le nœud v8.1.4.

L'exécution de --verbose --testPathPattern=<path/to/file> entraîné l'impression des journaux. Sinon, il est avalé.

Quelqu'un peut-il fournir une petite reproduction qui échoue sur jest 21.2.0 et les nœuds actuels (donc 4.8.4, 6.11.4 ou 8.7.0) ?

Il n'est pas nécessaire de configurer verbose ou des configurations 7.4.0 à 8.0.0 . C'est mes observations.

Utilisation de [email protected]

C'est tellement frustrant ! J'ai les dernières versions de tout et Jest coupe toujours la sortie console.log à des endroits apparemment aléatoires. Cela rend très difficile le débogage des tests défaillants.

Je viens de trouver la réponse à ça ! Si vous désactivez le mode verbeux, toute la sortie console.log apparaîtra ! Je pense que lorsque les sorties de Jest sont des trucs verbeux, il les écrit au-dessus de votre sortie des derniers console.logs.

Avez-vous un morceau de code reproduisant cela de manière cohérente ? Peut nous aider à éliminer l'incohérence sous-jacente à l'origine du problème.

J'ai utilisé expect(<value>).toEqual("someImpossibleValue") avec bail: false pour contourner ce problème lorsque j'essayais simplement de réparer quelque chose de cassé. Certainement pas idéal, mais rapide et sale. . .

Vous pourriez peut-être introduire une fonction suppose() similaire à expect(), mais qui n'abandonne pas.

en cours d'exécution v 22.0.4 pas de console.log .... ajoutez ceci à l'une des nombreuses autres raisons pour lesquelles je ne recommande pas la plaisanterie

@mvolkmann merci pour l'astuce sur le mode verbeux. Si le mode non-verbeux est la valeur par défaut en plaisantant, cela peut valoir la peine d'envisager un changement. Il ne me semble pas intuitif que console.logs que vous placez dans votre code ne s'affiche tout simplement pas. C'est la toute première chose fondamentale que l'on essaie lorsqu'un test échoue.

(nœud v9.3.0 et jest v20.0.4 ici)

jest ^21.2.1 et node 8.9.4

Parfois, Jest ne lance toujours pas les journaux de la console, l'option --verbose ne résout pas le problème pour moi. Je ne comprends pas pourquoi ce sujet est clos.

@fega puisque personne n'a fourni de boîtier de reproduction sur

$ jest --verbose

cette commande affichera tous les journaux de la console

@odykyi ne fonctionne pas pour moi. blague 22.1.0 et v8.9.4

comportement bizarre. Si je définissais verbose sur false mes instructions console.log étaient imprimées.

sur [email protected] , [email protected] , et en utilisant --forceExit , je ne vois pas le résultat de console.log de mon code testé à moins que je définisse explicitement verbose à false ou supprimez le drapeau --forceExit (que j'utilise temporairement).

sur [email protected] , [email protected] , et en utilisant --forceExit, je ne vois pas la sortie de console.log de mon code testé à moins que je définisse explicitement verbose sur false ou supprime l'indicateur --forceExit (qui j'utilise temporairement).

Voir exactement le même comportement que celui indiqué ci-dessus. [email protected] , [email protected].

console.logging avant que done() soit appelé, mais la sortie n'est pas affichée avec --forceExit . Lorsque --forceExit est supprimé, la sortie console.log s'affiche à la fin.

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

Alors, la solution évidente n'est-elle pas ici avant de forcer la sortie du vidage du tampon de sortie que la plaisanterie a en interne?

Nous avons un cas de test pour cela : https://github.com/facebook/jest/blob/497be7627ef851c947da830d4a8e21046f847a78/integration-tests/__tests__/console_log_output_when_run_in_band.test.js#L24 Est-il défectueux d'une manière ou d'une autre ?

Quelqu'un peut-il mettre en place un dépôt de reproduction auquel nous pouvons jeter un coup d'œil ?

Ajout rapide : jest --no-cache semble également signifier que console.logs ne s'affiche pas.

Avec Node 9.7.1 et jest 22.4.2 avec babel 7 en utilisant verbose semble fonctionner très bien pour afficher les journaux de la console à partir des tests :

package.json

"dependencies": {
  ...
},
"jest": {
  "verbose": true
}

Cela fait un certain temps que cela n'a pas nécessité l'intervention de l'utilisateur, mais il semble que le remède ait été cohérent.

Ce problème nous harcèle également depuis un certain temps maintenant, d'abord avec une sortie tronquée de manière aléatoire, maintenant une sortie totalement ignorée. Pour reproduire, clonez la branche dev/dexie-search-index de ce référentiel :
[email protected] :WorldBrain/Memex.git

Ajoutez cette ligne quelque part dans insertTestData() dans src/search/index.test.ts :
console.log('!?!?!?!!?!?!!?'); expect(1).toBe(2)

Testé avec les versions Node.js 6.11 et 8.10. Veuillez résoudre ce problème dès que possible, car cela rend le codage beaucoup plus lent :(

@frankred merci. J'ai mis verbose: "false" et ça marche.

Je suis tombé sur ce problème https://github.com/evanw/node-source-map-support/issues/207 hier et cela semblait terriblement similaire à ce problème ici.

La raison pour laquelle cela pose problème est que les écritures dans process.stdout dans Node.js sont parfois asynchrones et peuvent se produire sur plusieurs ticks de la boucle d'événements Node.js. Cependant, l'appel de process.exit() force le processus à se terminer avant que ces écritures supplémentaires sur la sortie standard puissent être effectuées.

https://nodejs.org/api/process.html#process_process_exit_code

Je n'ai pas vérifié le code, mais si process.exit() est utilisé avec --forceExit , cela expliquerait pourquoi la sortie du journal est manquante.

Je viens d'ajouter une solution qui a fonctionné pour moi dans ce problème connexe : https://github.com/facebook/jest/issues/3853#issuecomment -375183943

@ledbit Cela n'a pas fonctionné pour moi. Wow un problème qui a duré un an et demi et toujours pas de solution.

C'est vrai, mais il n'y a toujours pas grand-chose à faire pour les développeurs.

J'ai trouvé ce problème le plus souvent dans un appel asynchrone imbriqué dans un exemple asynchrone. Je ne suis pas tout à fait sûr que ce soit le cas pour quelqu'un d'autre, mais montrer son utilisation de console.log serait sûrement utile pour résoudre ce problème.

C'est certainement ce qui se passe pour moi. De quoi avez-vous besoin de ma part pour que vous puissiez le réparer ?

Le 22 mars 2018, à 8h32, Dennis Brown [email protected] a écrit :

C'est vrai, mais il n'y a toujours pas grand-chose à faire pour les développeurs.

J'ai trouvé ce problème le plus souvent dans un appel asynchrone imbriqué dans un exemple asynchrone. Je ne suis pas tout à fait sûr que ce soit le cas pour quelqu'un d'autre, mais montrer son utilisation de console.log serait sûrement utile pour résoudre ce problème.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/facebook/jest/issues/2441#issuecomment-375349444 , ou coupez le fil https://github.com/notifications/unsubscribe-auth/ADrayIO4NBB2dZM1XL8ZQO32W9SUnu2Yks5tg8QCgaJpU

Mieux encore, allez-y ! Voici mon dépôt. https://github.com/RALifeCoach/handandfootserver.git

Exécutez jest à partir de npm ou exécutez à partir de la ligne de commande. Vous verrez qu'il y a beaucoup, beaucoup de console.logs, mais la plupart sont masqués.

Là, l'équipe de développement a tout ce dont elle a besoin. Veuillez résoudre ce problème.

Le 22 mars 2018, à 8h36, Christopher Oliphant [email protected] a écrit :

C'est certainement ce qui se passe pour moi. De quoi avez-vous besoin de ma part pour que vous puissiez le réparer ?

Le 22 mars 2018, à 8h32, Dennis Brown < [email protected] [email protected] > a écrit :

C'est vrai, mais il n'y a toujours pas grand-chose à faire pour les développeurs.

J'ai trouvé ce problème le plus souvent dans un appel asynchrone imbriqué dans un exemple asynchrone. Je ne suis pas tout à fait sûr que ce soit le cas pour quelqu'un d'autre, mais montrer son utilisation de console.log serait sûrement utile pour résoudre ce problème.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/facebook/jest/issues/2441#issuecomment-375349444 , ou coupez le fil https://github.com/notifications/unsubscribe-auth/ADrayIO4NBB2dZM1XL8ZQO32W9SUnu2Yks5tg8QCgaJpU

@RALifeCoach en regardant votre repo maintenant, il y a pas mal de journalisation là-bas. Vous voulez savoir quelle journalisation en particulier vous manque ?

Exécuter. Vous verrez une sortie, mais une grande partie est écrasée.

Le samedi 14 avril 2018, 03h10 Simen Bekkhus [email protected]
a écrit:

@RALifeCoach https://github.com/RALifeCoach en regardant votre repo maintenant,
il y a pas mal de logs là-bas. N'oubliez pas de vous connecter
particulier vous manque?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/facebook/jest/issues/2441#issuecomment-381318608 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/ADrayHQCc8C0NmMmrtE7mEo2jN999CChks5tocsKgaJpZM4LVbUv
.

Je ne sais pas ce que vous entendez par écrasé. Est-ce que quelque chose est sorti vers la console alors effacé?

Si six lignes sont écrites à l'aide de console.log, les 6 apparaissent brièvement puis
le résumé du test chevauche certaines des 6 lignes.

Le samedi 14 avril 2018, 08:58 Simen Bekkhus [email protected]
a écrit:

Je ne sais pas ce que vous entendez par écrasé. Est-ce que quelque chose est sorti vers le
console alors effacée?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/facebook/jest/issues/2441#issuecomment-381339074 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/ADrayF0P5SqpHjaAAYcPaIAF7ubSMVRTks5tohyIgaJpZM4LVbUv
.

Je vis également ce que @RALifeCoach décrit. Je verrai la sortie de mon journal clignoter à l'écran au fur et à mesure que les tests se déclenchent, puis lorsque je fais défiler vers le haut, cette sortie n'est plus là.

Il semble que ce soit toujours un problème, même sur le nœud 8.11.1. Peut-être devrions-nous signaler un nouveau bogue et nous y référer ?

J'ai toujours le même problème dans le nœud v8.9.0.

Je peux confirmer le commentaire de » @RALifeCoach propos de la sortie du journal étant « écrasé » - J'ai finalement eu les journaux pour montrer par marquage chacun avec une chaîne de caractères particulière (par exemple @@@ ) et en cours d' exécution:

yarn test --verbose | grep '@@@'

C'est un hack terrible (vous perdez toute la coloration de la console, mais vous voyez toujours des échecs de test et un résumé de test final) mais c'est la seule chose qui a fonctionné jusqu'à présent. J'ai tout essayé dans les commentaires ci-dessus. Notez que l'argument --verbose est nécessaire pour cette solution (et il est implicitement combiné avec --watch via react-scripts ).

[Utilisation de react-scripts forked pour utiliser le dernier Jest v23.0.0, nœud v8.11.2]

La configuration de "verbose": true dans package.json aide. Les journaux s'affichent en bas de la sortie.

Homme pour un problème clos, je regarde toujours les gens se plaindre de cela depuis sa création il y a 2 ans.

Je pense qu'il y a du code dans Jest qui nous fait une blague et "détourne" console.log(),
en faire un no-op, quelque chose comme...

console.log = function(){ /* do nothing */}

Le remède pour réinitialiser console.log est, assez ironiquement - voir https://stackoverflow.com/questions/7089443/restoring-console-log
-- pour supprimer console.log

delete console.log
console.log("Can you hear me now, Jesters...?");

... et tout d'un coup -- Voila ! -- comme un Phoenix des flammes -- console.log() fonctionne à nouveau dans Jest... !
Jest imprime même "console.log (informations de localisation)" avant d'enregistrer votre message...

>

console.log __tests__\libarray-helpers.test.js:35
Pouvez-vous m'entendre maintenant, bouffons...?

De plus, j'ai récemment utilisé "logatim" isomorphe https://www.npmjs.com/package/logatim au lieu de console.log(), et il
semble immunisé contre les tentatives de détournement de Jest... (peut-être que cela réinitialise console.log...)

Vous pouvez même "détourner" de manière préventive la console.connectez-vous pour logatim
pour enregistrer un message de niveau "info" en vert...

// const logatim = require('logatim') // ES5
import logatim from 'logatim' // ES6
/* ... */
console.log = function(...args){ logatim.green.info("[INFO]",...args) } // ES6

(S'il vous plaît, n'interprétez pas ma jocosité comme une bellicosité... où est la joie de nommer un bon produit Jest si vous ne pouvez pas en plaisanter un peu...)

Avant de répandre la haine, @yanshuf0 , pensez aux outils gratuits et ouverts dont vous bénéficiez clairement. Vous avez choisi d'utiliser Jest. Si vous ne l'aimez pas, vous pouvez choisir de partir (ou de le réparer vous-même, l'équipe est sympathique et ouverte aux RP).

J'avais ce problème d'"écrasement" (Windows 10, terminal VS Code, projet node.js) et alors que je jouais avec, le bogue a cessé de se produire. Je pensais que cela avait cessé de se produire parce que j'avais cessé d'utiliser --watch ou parce que j'avais ajouté une option "verbose": false , mais l'annulation de ces modifications n'a pas fait revenir le bogue.

Je dois cependant demander si Jest n'associe pas intentionnellement la sortie du journal au test qui l'a produite ? Pendant un certain temps, toutes les sorties de la console étaient inférieures à tous les résultats de test, mais maintenant, elles sont affichées au-dessus de tous les résultats de test. Tellement aléatoire.

L'indicateur --watchAll l'a bloqué. maintenant ça marche pour moi

Après avoir utilisé jest pendant des mois, cela m'est également arrivé à l'improviste avec le nœud 8.9. Une minute, console.log s'affichait correctement, la suivante, il ne fonctionnait plus. Je me suis retrouvé sur ce fil et j'ai essayé plusieurs choses. Ne pas utiliser --watch résolu le problème, mais j'ai dû réexécuter ma commande de test à chaque fois. L'utilisation de --watch --verbose false résolu le problème et exécuterait automatiquement mes tests.

Trouver le même problème ici, merci pour le correctif temporaire @bkempner

Peut confirmer qu'il s'agit d'un problème à la fois dans 22.4.4 et 23.4.1 (en date de ce commentaire). Les drapeaux que j'utilise sont :

$ jest --forceExit --runInBand --bail --ci --json --outputFile=/tmp/jest_results.json

Un autre problème sur le même sujet a suggéré d'ajouter l'option --json , qui a fonctionné pendant un certain temps... Peut-être que certaines dépendances ont changé depuis, mais les sorties STDOUT et STDERR sont toujours supprimées. Le plus proche de tout ce qui fonctionnait était d'utiliser --watch ; parfois, une partie de la sortie était collée à la fin sans être écrasée.

J'ai trouvé que --silent est vrai par défaut, le définir sur faux affichera le console.log : jest --silent=false

On dirait une tonne de rapports sur cet alambic, quelque chose est clairement encore cassé. Cela a été fermé en tant que dupe de #2166 qui est maintenant fermé, mais cela persiste.

@thymikee Pourrions-nous rouvrir ce problème ?

Je rouvre ceci, car le problème est partiellement de retour et nous devons le résoudre.

En v23, le problème apparaît en mode montre, puisque nous avons modifié son fonctionnement sous le capot pour exécuter presque toujours les tests en parallèle, afin que le TTY ne soit pas bloqué et que l'on puisse annuler facilement les tests de longue durée : https://github. com/facebook/jest/pull/6647.
Le seul cas où nous ne générons pas de travailleurs en mode montre est lorsque nous avons exactement 1 test à exécuter et qu'il est relativement rapide (s'exécute en moins de 1 s) - dans ce cas, nous devrions toujours voir console.log s apparaître comme toujours.

Dans mon cas, tous les tests en cours d' exécution en mode veille ne se connecte correctement. Si j'utilise le mode modèle pour filtrer sur une seule classe de test, la journalisation est tronquée

Selon le commentaire de @davidgilbertson (https://github.com/facebook/jest/issues/2441#issuecomment-286248619) en supprimant verbose: true dans mon package.json et en supprimant --verbose de mon les indicateurs de ligne de commande me permettent d'afficher les journaux de la console qui étaient autrement cachés. C'est assez déroutant.

J'ai verbose: true dans mon package.json et je constate que les déclarations console.log sont parfois là et parfois non (si j'en ai comme 10 en tout regroupées, elles semblent apparaître, mais pas pour un seul) - je pense que c'est peut-être un problème asynchrone

J'ai aussi ce problème de temps en temps, j'active runInBand (https://jestjs.io/docs/en/cli.html#runinband) et cela le résout.

@ndelangen c'est curieux - je me demande si c'est peut-être un problème asynchrone alors. Je pensais que Jest avait collecté tous les journaux de console.logs et les a ensuite imprimés à la fin, non ?

Le problème est récurrent maintenant même si je n'utilise pas verbose .

--runInBand ne résout pas le problème pour moi. La seule solution de contournement fiable jusqu'à présent consiste à simplement enregistrer quelque chose plusieurs fois afin qu'une partie de la sortie ne soit pas écrasée par une plaisanterie.

J'ai fait quelques analyses, ajouté quelques commentaires et réussi à créer un patch partiel ici :

https://github.com/facebook/jest/issues/3853#issuecomment -413622844

Éditer:

repo contenant du code à reproduire facilement disponible ici : https://github.com/spion/jest-logging-repro

analyse de la sortie ici : https://gist.github.com/spion/bbb34c5abc1230a37ad5f4f01336b8df

Le patch est partiel car

• de nombreux tests d'intégration échouent maintenant en raison des changements nécessaires dans la sortie
• parfois (malheureusement) la sortie du journal apparaît après la dernière mise à jour du statut - la raison en est probablement le fait que les flux du processus enfant sont vidés après que le processus enfant a envoyé le message de réussite au parent.

@philraj même problème pour moi .. je dois me connecter plusieurs fois pour voir de manière fiable le message de journal prévu

comment ce problème n'est-il pas majeur et n'est-il pas résolu au plus vite ? comment est ce problème ouvert depuis 2016 ??

Mise à jour : avec ce patch, je n'en suis plus qu'à 8 tests ratés :

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).

Il s'agit principalement de ne pas s'attendre à ce que FORCE_COLORS dans process.env, hg scm et packages/jest-runner/src/__tests__/test_runner.test.js ne se moquent pas complètement des flux (il n'y a donc pas de méthodes pipe dessus.

À ce rythme, je pourrai soumettre un PR qui corrige cela la semaine prochaine... à condition que je trouve un correctif pour la sortie du journal apparaissant une fois le rapport complet terminé.

Comme @bkempner l'a dit, l'utilisation de --watch --verbose false résout le problème.

La sortie de la console dans --watch écrasée par un simple déplacement du curseur est cohérente avec ce que je vois. La présence/absence de --verbose , --maxWorkers 1 , --runInBand ne produit pas de succès.

Ma solution de contournement actuelle est jest --watch | cat . Je perds toute la couleur et reste en haut de la fenêtre, mais j'obtiens la sortie de la console.

Ou, TERM=dumb jest --watch . Je perds le fait de rester en haut de la fenêtre, mais j'obtiens la couleur et la sortie de la console.

J'ai eu le même problème.

Ce qui a fonctionné pour moi, c'est d'utiliser console.debug

TERM=dumb répare aussi pour moi

FWIW, TERM=dumb le corrige aussi pour moi

désactiver verbose dans la configuration jest a fonctionné pour moi 0_o\

L'ajout de --verbose false au script "test" package.json a résolu le problème pour moi. Je n'aurais jamais trouvé ça sans ce fil.

par exemple

"scripts": {
    "test": "jest --watch --verbose false"
}

Bizarre comment certaines des dernières consoles disparaissent mais pas toutes, corrigé avec --verbose false dans ma commande watch.

Fonctionne bien lorsque vous exécutez sans --watch , c'est donc quelque chose à propos de l'indicateur de surveillance qui le fait.

Ce qui est tellement ironique, c'est que c'est plus verbeux quand console.log fonctionne !

J'ai commencé à remarquer ce problème avec verbose dans Jest 23.6, je suis revenu à 23.5 et je le vois toujours. Si j'exécute --clearCache cela corrige le verbeux pendant un certain temps jusqu'à ce qu'il échoue à nouveau. Je ne sais pas quel est le déclencheur, comme beaucoup d'échecs de journal ou quelque chose dans ce sens. Une fois que cela se produit, Jest semble corrompre le cache. J'essaie le --verbose false et je vois si cela l'empêche d'avancer.

Merci @jamespolanco L' utilisation de l'option --clearCache résolu le problème pour moi (pour le moment). Je vais exécuter mes tests en utilisant l'option --no-cache et voir si cela empêche le problème de se reproduire à l'avenir.

EDIT : j'aurais dû mentionner que mon problème était que seuls certains de mes messages console.log étaient imprimés. J'ai utilisé 5 console.log lignes dans un test et seules les 3 premières lignes ont été imprimées. L'utilisation de --clearCache résolu ce problème pour moi. Peut-être y a-t-il un problème différent où aucun console.log n'apparaît ?

J'ai aussi ce problème. J'ai essayé d'utiliser console.log, console.debug et console.error. J'ai également essayé d'utiliser le drapeau --no-cache. Dans tous les cas, ma déclaration de console est complètement ignorée.

J'ai aussi ce problème en mode montre. Version 23.6.0

Je l'ai même enregistré si quelqu'un veut voir par lui-même :

comme les autres, il n'est effacé que lors de l'exécution avec --watch . J'ai essayé --verbose false et cela n'a pas aidé.

J'ai aussi le même problème.

Je rencontre également cela lorsque j'utilise verbeux ou en mode montre

Croyez-le ou non, je me connecte parfois en lançant une erreur. Faire également node --inspect node_modules/.bin/jest --runInBand mypath/to/my.test.js montre les vraies sorties console.log dans mon cas.

Nœud v9.11.1
Blague : v23.6.0

Configuration de Jest dans package.json :

  "jest": {
    "preset": "react-native",
    "verbose": true,
    "testEnvironment": "node",
    "haste": {
      "defaultPlatform": "android",
      "platforms": [
        "android",
        "ios",
        "native"
      ],
      "providesModuleNodeModules": [
        "react-native"
      ]
    },
    "setupFiles": ["<rootDir>/__tests__/setup"]
  },

Je confirme que ce problème est avec verbeux. Le problème est que le calcul du nombre de lignes est faussé lorsque verbose est activé.

Si quelqu'un peut m'indiquer l'endroit où il imprime le message, je peux essayer.

Vous pouvez atténuer l'émission en utilisant jest-watch-toggle-config pour le moment.

Configurez-le comme ceci :

module.exports = {
  "watchPlugins": [
    ["jest-watch-toggle-config", { "setting": "verbose" }]
  ]
}

Lorsque vous exécutez votre test, appuyez sur v pour activer le verbeux, puis à nouveau sur v pour le désactiver .

Après cela, tant que vous restez silencieux, vous pouvez voir tous les journaux.

--verbose=false résolu le problème pour moi lors du test de l' enzyme superficielle . Les console.logs fonctionnaient cependant sans le correctif pour enzyme mount .

Cela suggère une différence entre la façon dont les erreurs sont enregistrées par le moteur de rendu react-test et la façon dont elles sont enregistrées par le moteur de rendu intégré de react (puisque l'enzyme ne dérange pas du tout les fonctions de la console)

Pour info, ce PR résout le problème pour moi - https://github.com/facebook/jest/pull/6871

Ce n'est pas encore prêt, il pourrait avoir besoin d'un changement d'approche - mais il affiche toutes les données enregistrées en mode détaillé.

Je n'ai pas encore mis à jour (jest exécuté le 22.4.2) mais en utilisant le mode de surveillance, mes journaux ne s'afficheraient pas. L'exécution avec --runInBand corrigé en mode montre.

    "test": "jest --watch --runInBand",
    "test:once": "jest",

Je n'ai pas mis à jour non plus (Jest 23.6.0), et l'exécution avec "jest --watch --verbose=false" le corrige également pour moi.

J'adorerais que les personnes ayant des problèmes pour tester le PR mentionné ci-dessus. Il est disponible en jest@beta ( 24.0.0-alpha.9 ce moment)

Alors laine ajoute jest@beta ?

ons. 19. des. 2018 kl. 16:46 skrev Simen Bekkhus [email protected] :

J'adorerais que les personnes ayant des problèmes pour tester le PR mentionné ci-dessus. C'est
disponible dans jest@beta (24.0.0-alpha.9)

-
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/2441#issuecomment-448641697 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AAM5P7ijQjSbWB0-zzDCfC9Uggyk5RGoks5u6l9EgaJpZM4LVbUv
.

>

Tarjei Huse
Mobile : 920 63 413

@tarjei , oui :

yarn add --dev jest<strong i="7">@beta</strong>

Ça marche pour moi. ??

C'est vraiment idiot, mais juste au cas où cela aiderait quelqu'un d'autre, je travaille sur un nouveau projet (pour moi) - jest fonctionnait avec l'option --silent qui désactive la sortie. J'ai supprimé cela et je vois des journaux maintenant 🤦‍♂️

Remarquez que lorsque le verbeux est activé (je le bascule en utilisant jest-watch-toggle-config ), une partie du journal de la console est bloquée en version bêta.

--verbose=false

Cela a fonctionné pour moi.

J'ai remarqué que certains console.log() fonctionnaient alors que d'autres ne fonctionnaient pas dans mes tests (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
*/

Il se passe quelque chose de très étrange, avec les tests async où le premier console.log du test asynchrone n'est pas enregistré, ainsi que celui qui suit le await n'est pas enregistré.

Ajoutez un peu plus de console.log dans ce test async et vous commencerez à remarquer un comportement encore plus étrange comme certains des journaux après que le await fonctionne soudainement 🤷‍♀️ 🤷‍♂️

Alors, ce que @philwhln a écrit ci-dessus il y a deux ans

Comme je ne peux pas isoler cela dans un test simple, je suppose que cela a quelque chose à voir avec l'exécution d'un test asynchrone plus complexe.

Semble avoir une part de vérité.

--verbose=false

A également fonctionné pour moi dans ce cas.

@DanweDE pouvez-vous vérifier si la dernière version alpha yarn add jest<strong i="6">@beta</strong> --dev résout le problème pour vous, même avec verbeux défini sur true ?

L'ajout de --verbose false résolu le problème. Cela semble un peu peu intuitif :)

Est-ce que c'est réglé ? Je ne vois toujours pas de console.logs sur "jest": "23.6.0"

@iDVB Si vous lisez le fil quelques commentaires ci-dessus, vous verrez qu'il existe une version bêta qui est censée résoudre le problème. Essayez cela et signalez si cela résout votre problème pour aider @spion

De plus, tous ceux qui viennent ici pour dire --verbose false ou --verbose true ou toute combinaison de drapeaux ou de versions Node ou Jest ont résolu leur problème, veuillez essayer la version bêta et signaler si elle résout votre problème sans votre solution de contournement.

les journaux de la console dans les classes que je teste s'affichent

@philraj, nous sommes passés à la version bêta "24.0.0-alpha.9" chez @leaplabs et cela fonctionne parfaitement. Dans le sens où je n'ai vu aucun journal disparaître depuis la mise à niveau.

Peut également confirmer, fonctionne sur 24.0.0-alpha.9 sans aucun argument de ligne de commande.

Je suis relativement nouveau sur React et Jest. Je n'ai pas pu obtenir de journaux cohérents en utilisant les valeurs par défaut de create-react-app. J'ai éjecté et maintenant les journaux fonctionnent correctement. Je ne pense pas que l'éjection ait changé la version de Jest. Peut-être que cela vient de changer l'un des paramètres de fonctionnement de Jest. C'est avec 23.6.0 .

Lors de l'utilisation de 24.0.0-alpha.16 je ne vois aucun journal de la console à moins d'ajouter verbose=false .

J'obtiens également des résultats assez incohérents avec cela sur

--verbose=false corrigé cela pour moi aussi 🎉

J'utilise 24.1.0 et cela fonctionne même sans option détaillée. Cependant, il ne produit aucune instruction console.log dans le fichier de test lorsque le fichier de test contient, par exemple. référence à la classe, qui n'est pas importée. Par example

C'est une erreur de ts-jest et pas vraiment pertinent ici

Oui, mais lorsque cette erreur se produit, la sortie du journal de la console ne s'affiche pas. Est-ce toujours pertinent pour ts-jest ? Je ne sais pas très bien de quoi chaque bibliothèque autour de jest est responsable.

IDK comment fonctionne ts-jest , mais s'il n'exécute aucun test sur les erreurs de type, cela expliquerait pourquoi ils manquent - le code ne s'exécute jamais

J'ai toujours du mal à faire fonctionner console.log ici. Je reçois occasionnellement des journaux, mais il ne semble pas y avoir de modèle discernable de réussite.

J'utilise Jest 24.7.1 et j'ai également essayé 24.7.1 et 24.2.0-alpha.0 .

Les paramètres verbose=false et verbose=true n'ont pas réussi à fournir de correctif.

J'ai également essayé d'utiliser le nœud v10.8.0 et v6.17.1 , également sans correctif.

Y a-t-il quelque chose qui manque ici ?

@mulholio êtes-vous sûr à 100% d'utiliser une blague installée localement ? J'ai signalé des problèmes dans le passé qui ne se produisaient que parce que j'avais une ancienne version globale d'un package qui s'exécutait au lieu de celle installée localement.

Oui, aucune version globale de Jest installée

Je peux confirmer qu'il n'a pas été résolu. parfois console.log fonctionne et parfois non, à quel point je suis confus.
mon environnement comme suit :
blague 23.6.0
nœud v8.13.0
et mon 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"],
}

ouais, après avoir supprimé verbose:true , ça semble bien

Je vois aussi ce bug, pouvons-nous ré-ouvrir ce problème ?

Pour info : si j'utilise fit pour exécuter un seul test, mes console.log n'ont rien généré. Lorsque j'ai exécuté toute la série de tests, les console.log s fonctionnaient très bien.

En rencontrant le même problème, certains journaux de la console sont "mangés". Pour ceux qui ont ce problème, pouvez-vous vérifier mais cloner plusieurs journaux de console ?

console.log('ok');
console.log('ok');
console.log('eaten up');

Il semble que le tampon de l'instruction [PASS] écrive sur les 2 dernières lignes du journal de la console (je peux voir une partie du numéro de ligne du journal de la console à la fin de l'instruction Pass)

+1000

Cela semble vraiment idiot, mais assurez-vous de yarn build avant les tests !

Toujours pas de sortie avec --verbose=true ou --verbose=false lors de l'utilisation de [email protected] - je ne sais pas pourquoi c'est toujours un problème 3 ans après qu'il a été initialement enregistré.

Avez-vous essayé d'utiliser le drapeau jest --runInBand pour voir si cela le résout en exécutant des tests en série ? Quelqu'un m'en a parlé, mais n'a pas eu l'occasion de le tester.

Merci, ça marche ! Mais pourquoi ne pas le définir par défaut pour avoir la sortie de console.log ..

C'est toujours un problème pour moi, [email protected]

J'ai trouvé un correctif en fait, les 2 dernières lignes du dernier cas de test (en cascade) sont remplacées, alors faites-en votre dernier cas de test

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

Pour ceux qui utilisent ts-jest , j'ai dû désactiver les diagnostics pour voir le console.logs
jest.config.js

  globals: {
    'ts-jest': {
      diagnostics: false,
    },
  },

Pour ceux qui utilisent ts-jest , j'ai dû désactiver les diagnostics pour voir le console.logs
jest.config.js

  globals: {
    'ts-jest': {
      diagnostics: false,
    },
  },

Cette option n'a pas fonctionné pour nous. Nous avons également essayé de définir verbose = false ce qui n'a pas aidé non plus.

Notre environnement:

• Nœud 10.16.0
• blague 24.8.0
• ts-jest : 24.0.2
• tapuscrit 3.5.2
• @types/blague 24.0.15

Il semble que le tampon de l'instruction [PASS] écrive sur les 2 dernières lignes du journal de la console (je peux voir une partie du numéro de ligne du journal de la console à la fin de l'instruction Pass)

Cela semble être le cas pour moi ([email protected]). Sur mon système, la ligne de sortie du terminal avec [PASS] semble faire clignoter du contenu avant d'être effacé.

Vivre ce problème aussi.

Je ne peux pas me connecter avec l'une des solutions ci-dessus, mais comme solution de contournement, je m'attends à échouer avec la valeur et à vérifier le diff :

expect(thingIWantToLog).toBe({})

Cela s'est également produit: il semble que la sortie "PASS: ..." écrase la sortie standard, donc votre "dernier" console.log sera mangé.

Si --verbose=false ne fonctionne pas, vous pouvez ajouter un tas de nouvelles lignes sacrificielles ( \n ) à votre dernier console.log.

Avez-vous essayé d'utiliser le drapeau jest --runInBand pour voir si cela le résout en exécutant des tests en série ? Quelqu'un m'en a parlé, mais n'a pas eu l'occasion de le tester.

L'ajout de ce drapeau a aidé à résoudre le problème.
De temps en temps, il n'affichait pas non plus les sorties console.log.
En utilisant cette commande :
npm test -- --verbose --runInBand -t "My Test Name"

Versions de nœud et NPM :
node v8.16.0
npm 6.4.1

C'est ma piste de travail :

npm install --save-dev sprintf-js

Dans votre plaisanterie setupTest.js , ou n'importe où :

import {sprintf} from 'sprintf-js';

console.log = (msg, args) => {
    const str = sprintf(msg, args);
    process.stderr.write(str + '\n');
  };

Toujours pas de sortie avec --verbose=true ou --verbose=false lors de l'utilisation de [email protected] - je ne sais pas pourquoi c'est toujours un problème 3 ans après qu'il a été initialement enregistré.

C'est mon jest.config.js et cela a fonctionné pour moi.
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,
};

Alors dans package.json j'ai :

"scripts": {
  "test": "jest --config ./jest.config.js",
}

Exécutez ensuite votre suite de tests spécifique avec cette commande :

yarn test -- -t 'test-suite-name-here'

--verbose=false semble avoir fonctionné pour moi. Merci!

Jest cacher les journaux et les avertissements lorsque vous passez l'option --silent
Essayez yarn jest cela devrait fonctionner

Ce bug est tellement ennuyeux... 3 ans...

désactiver --silent
et pour les tests ts utilisant la solution ts-jest @mr-madamin qui fonctionne pour moi !

Ne pas utiliser verbose ou silent , avoir essayé --runInBand , TERM=dumb , exécuter tous les tests par rapport à un seul fichier de test, et console.log apparaît lorsque placé dans les blocs de configuration mais pas dans les blocs it() .

Lorsque tout le reste échoue, vous devriez toujours pouvoir faire :

require('fs').writeFileSync('./output', data);

Mais je me sens comme un homme des cavernes utilisant une pierre pour casser une cacahuète.

modifier : "jest": "^24.9.0"

J'utilise cette commande et ça marche :

npm test -- --runInBand -t "My Test Name"

Vous pouvez spécifier votre nom de test après l'indicateur -t pour exécuter des tests individuels ou des groupes de tests sous le même describe() .

Ne pas utiliser verbose ou silent , avoir essayé --runInBand , TERM=dumb , exécuter tous les tests par rapport à un seul fichier de test, et console.log apparaît lorsque placé dans les blocs de configuration mais pas dans les blocs it() .

Lorsque tout le reste échoue, vous devriez toujours pouvoir faire :

require('fs').writeFileSync('./output', data);

Mais je me sens comme un homme des cavernes utilisant une pierre pour casser une cacahuète.

modifier : "jest": "^24.9.0"

J'étais ravi de commencer enfin à utiliser Jest sur le backend pour plus d'uniformité. Au lieu de cela, je rencontre ce problème et, pour le moment, je reviens à moka/proxyquire. Aucune sortie console.log visible (dans les modules ou les cas de test) et après avoir passé plusieurs heures dessus, aucune des solutions de contournement ne semble aider. Pas intéressé par les solutions de contournement qui impliquent la journalisation dans des fichiers ...

Testé contre le nœud 8/10 LTS avec "jest": "^24.9.0",

Ouais. Je suis sur le bord aussi. Il semble qu'il soit plus populaire ici de résoudre le problème et de recommander des piratages au lieu de résoudre des problèmes évidents pendant plus de 3 ans.

Bonjour Samlevin et Pavelloz,
As-tu essayé cette option ?

J'utilise cette commande et ça marche :
npm test -- --runInBand -t "My Test Name"

Vous pouvez spécifier votre nom de test après l'indicateur -t pour exécuter des tests individuels ou des groupes de tests sous le même describe().
Pourriez-vous s'il vous plaît me dire si cela fonctionne? Comme je l'utilise depuis un moment maintenant.

Voici une capture d'écran avec un exemple de code et de sortie.
REMARQUE : au cas où vous ne le sauriez pas, le fichier console.lg est imprimé au-dessus de tous les autres rapports, et non à la fin où vous voyez le rapport de couverture de code ou la reprise d'erreur.

Mes versions Node et NPM :

node v8.16.0
npm 6.4.1

J'étais ravi de commencer enfin à utiliser Jest sur le backend pour plus d'uniformité. Au lieu de cela, je rencontre ce problème et, pour le moment, je reviens à moka/proxyquire. Aucune sortie console.log visible (dans les modules ou les cas de test) et après avoir passé plusieurs heures dessus, aucune des solutions de contournement ne semble aider. Pas intéressé par les solutions de contournement qui impliquent la journalisation dans des fichiers ...

Testé contre le nœud 8/10 LTS avec "jest": "^24.9.0",

J'ai testé toutes les solutions de ce fil.

Juste pour vérifier si rien n'a changé à cet égard :

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

Éditer

REMARQUE : au cas où vous ne le sauriez pas, le fichier console.lg est imprimé au-dessus de tous les autres rapports, et non à la fin où vous voyez le rapport de couverture de code ou la reprise d'erreur.

Je ne vérifiais même pas le bas du rapport, mais c'est exactement là que mon journal a atterri. Donc je suppose que cela fonctionne, mais pas systématiquement/de la même manière pour tout le monde.

Merci de votre aide.

La question est de savoir à quel point cela nuit aux performances, mais c'est pour un autre jour, la journalisation est plus importante.

Vous avez raison @pavelloz , lorsque vous exécutez les tests avec l'option --runInBand, cela prendra plus de temps pour terminer les tests car cela fait ceci :

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

Donc, ce que je fais, c'est n'utiliser cette option que lorsque j'ai besoin de déboguer un problème sur un test.
Le reste du temps, exécutez simplement le test normalement.

Acclamations

composant const = peu profond(...)
console.log(component.debug())

C'est incroyable que cela n'ait pas encore été corrigé.

@ivandosreisandrade J'ai pu vérifier la solution de contournement du drapeau runInBand , mais pour le moment, je préfère ne pas perdre de temps à ajouter l'étape supplémentaire pour les autres développeurs, et je suis revenu à quelque chose qui se comporte comme prévu dès la sortie de la boîte. restera abonné pour voir si quelque chose change à cet égard

J'ai tout essayé dans ce fil et je ne peux toujours pas voir la sortie pour console.log. --runInBand ne résout pas le problème pour moi. En utilisant node@12 et la dernière blague. Le débogage avec le développement Web est assez difficile, ce serait vraiment utile si je pouvais au moins imprimer à l'écran pour voir pourquoi mon test unitaire échoue

@u84six avez-vous essayé ma solution ?
Voici le lien vers ma réponse sur le post.
https://github.com/facebook/jest/issues/2441#issuecomment -552368939

Acclamations

@ivandosreisandrade ce qui se passe, c'est que s'il y a une erreur dans le code (comme faire référence à une valeur indéfinie), il ne s'imprimera pas, même si l'appel console.log est avant l'erreur. Si tout dans le test réussit, je verrai le journal. Ce genre de comportement le rend totalement inutile pour le débogage.

@ivandosreisandrade à quoi ressemble votre package.json ? J'essaye de suivre ceci :

npm test -- --runInBand -t "Mon nom de test"

Mais je l'ai configuré comme ceci dans mon package.json

" test:unit ": "jest --verbose"

On pourrait penser qu'avec l'indicateur --verbose, cela permettrait à un console.log de passer, mais je n'arrive toujours pas à faire fonctionner console.log. Tellement frustrant!

@ivandosreisandrade à quoi ressemble votre package.json ? J'essaye de suivre ceci :

npm test -- --runInBand -t "Mon nom de test"

Mais je l'ai configuré comme ceci dans mon package.json

" test:unit ": "jest --verbose"

On pourrait penser qu'avec l'indicateur --verbose, cela permettrait à un console.log de passer, mais je n'arrive toujours pas à faire fonctionner console.log. Tellement frustrant!

@ u84six c'est mon packadge.json

"scripts": {
    "test": "jest test --coverage",
    ... 
},
...
"jest": {
    "verbose": true,
    "testMatch": [
      "**/tests/**/*.js?(x)"
    ],
    "moduleFileExtensions": [
      "js"
    ],
    "moduleDirectories": [
      "node_modules"
    ]
  }

Votre testMatch autorise les fichiers .js ou .jx ou .jsx , et votre moduleFileExtensions n'autorise que .js . Quelque chose ne va pas là-bas.

Ce n'est pas pertinent pour la cause :man_shruging:
C'est juste quel fichier localiser et exécuter des tests sur eux.

Je ne sais pas pourquoi le sujet est clos. Voici donc ma version de nœud - 13.12.10, npm -6.14.4
plaisanterie -24.9.0

Voici un test de base avec mock-fs
importer une maquette de 'mock-fs' ;
importer * en tant que fs depuis 'fs' ;
importer la pompe de « pompe » ;
importer * en tant qu'utilitaire depuis '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', () => {

    });
});

Je ne sais pas pourquoi cela se produit. Est-ce à cause de la boucle d'événement dans laquelle le fichier console.log est considéré comme traité dans le nextTick () uniquement après l'exécution des spécifications de test. Je m'excuse d'avoir soulevé ce problème, mais il semble plutôt fastidieux de déboguer chaque cas de test, plutôt que de simplement faire un o/p de console et de vérifier les données req.

Parce que vous devez retourner votre fichier Promesse promis pour plaisanter afin qu'il sache quand votre test est terminé - votre problème n'a rien à voir avec celui-ci.

J'ai contourné ce problème à des fins de débogage en mettant simplement ce que je voulais pour me connecter dans une instruction temporaire expect . Ainsi, au lieu de console.log(sketchyVariable) , utilisez expect(sketchyVariable).toEqual(42) .

Ce qui a fonctionné pour moi sur le nœud 8 :
Au lieu d'utiliser console.log , utilisez le journal de débogage intégré :

const util = require('util')
const myLogger = util.debuglog('myloggername')
myLogger('foobar')

Et commencez à plaisanter avec le drapeau du débogueur :

NODE_DEBUG=myloggername npm test -t "My Test Name"

Je voyais les journaux de la console apparaître sporadiquement lorsque je regardais un seul test. Parfois, je voyais tous les journaux, d'autres fois aucun, et d'autres fois j'en voyais certains mais pas tous. Chaque fois que le test était exécuté, je voyais quelque chose de différent. ??

--verbose=false corrigé pour moi. J'ai été surpris par cela, car je ne mets verbose sur true nulle part. Il s'avère que Jest le définira automatiquement sur true si vous exécutez un seul test . ??

s'il n'y a qu'un seul fichier de test en cours d'exécution, la valeur par défaut sera true.

https://jestjs.io/docs/en/configuration#verbose -boolean

Fil de discussion StackOverflow associé : https://stackoverflow.com/questions/48695717/console-log-statements-output-nothing-at-all-in-jest

jest ne gère pas bien la journalisation à plusieurs niveaux. cela devrait

• capturer et afficher tous les journaux capturés pour un test en cas d'échec par défaut
• avoir la possibilité de n'en afficher aucun, et
• avoir une option pour désactiver la capture.

c'est ça. vraiment pas compliqué.

Je suppose qu'ils capturent les journaux de la console car ils essaient d'imprimer une sortie asynchrone dans un ordre sensé lors de l'exécution des tests. Le problème est que si ce code de journalisation ne fonctionne pas pour un utilisateur, dans son environnement, il est à peu près rodé.

J'ai arrêté d'utiliser jest il y a des années, car je ne pouvais pas obtenir de manière fiable la sortie de la console lors du débogage des tests, peu importe les suggestions que j'ai suivies dans ce fil.

La morale de l'histoire est de ne pas jouer avec la console globale. JAMAIS. Si vous souhaitez fournir un enregistreur qui peut être activé ou désactivé, faites-le. Je l'utiliserai si je veux. Mais la console globale ne doit pas être perturbée.

Obtenez Outlook pour iOS https://aka.ms/o0ukef

De : earonesty [email protected]
Envoyé : mercredi 12 août 2020 12:33:23
À : facebook/jest [email protected]
Cc : Chris Grimes [email protected] ; Mentionnez [email protected]
Objet : Re : [facebook/jest] console.log ne s'affiche pas lors de l'exécution des tests (#2441)

jest ne gère pas bien la journalisation à plusieurs niveaux. il devrait capturer les journaux et les afficher en cas d'échec par défaut, avoir une option pour n'en afficher aucun et avoir une option pour tout afficher. c'est ça.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/facebook/jest/issues/2441#issuecomment-673011577 , ou désabonnez-vous https://github.com/notifications/unsubscribe-auth/AAFCNBK5MQEA6AJHEC52ZWDSALG6HANCNFSM4C2VWUXQ .

@halis J'utilise Jest par

Mon sentiment est que le jeu principal de Jest est d'être heureux de casser le comportement et la sémantique attendus de temps en temps si cela améliore considérablement l'expérience de test. Des choses comme le hissage automatique de jest.mock(...) signifient que les tests Jest ne sont pas strictement JavaScript (ou même ECMAScript) dans leur sémantique ; De même, le parallélisme signifie que toutes les méthodes intégrées renvoyant des vides comme console.log peuvent et doivent être traitées comme asynchrone, si elles peuvent améliorer les performances.

Est-ce une mauvaise chose? Clairement pas forcément, car Jest a énormément de succès. Mais je pense que Jest a la capacité de vous surprendre de temps en temps. Je suis à peu près sûr que 90% des utilisateurs de Jest n'ont aucune idée que leur code est transformé en AST pour passer des appels simulés, par exemple.

Je suis à peu près sûr que 90% des utilisateurs de Jest n'ont aucune idée que leur code est transformé en AST pour passer des appels simulés, par exemple.

QUEL

Essayez d'utiliser console.debug ou console.error

Vous pouvez utiliser --useStderr dans mon cas a résolu le problème car il transmet les messages directement

https://nodejs.org/api/process.html#process_a_note_on_process_i_o

J'ai encore eu du mal avec cela aujourd'hui et le drapeau --useStderr a corrigé pour moi. Merci @diomalta !

J'étais aux prises avec le même problème, les journaux ne s'affichaient pas lorsqu'un test échouait.

J'ai réussi à afficher mon console.log en définissant verbose: true dans mon jest.config