@thymikee Avez -vous une idée de pourquoi cela se produit?

Aucune idée, mais j'essaierais de minimiser l'exemple, par exemple en supprimant le texte dactylographié

Je suis capable de reproduire sans Typescript

Peut confirmer que le nœud 7.4 mange les journaux de la console, mais cela fonctionne sur les nœuds 7.5.0, 7.10.0, 8.0.0 et 8.1.2.
Veuillez mettre à niveau votre version de Node. Fermeture

@thymikee Qu'en est-il de Node 6, qui est la version actuelle de LTS ? (On dirait que je touche ça aussi, même si je ne l'ai pas encore assez débogué. Cependant, je suis limité aux versions LTS pour l'instant, donc je ne peux pas mettre à niveau).

Testé sur v6.11.0, affiche toujours console.log s.

Ah, je rencontre peut-être un autre problème. Merci, @thymikee , je vais revenir un peu plus au débogage.

J'exécutais Node 7.3.0 sans le savoir (mauvaise version via n) et il ne se connectait pas. Passé à 8.1.1 et il s'est connecté à nouveau.

@thymikee - Je ne vois pas en quoi c'est la solution ? ...Je ne parviens pas à mettre à jour ma version de nœud

Je suppose que je suis un peu confus sur la façon dont cela serait considéré comme un bogue de nœud et n'aurait pas au moins quelque chose à voir avec Jest lui-même. En utilisant Node v7.4.0, avec Jest v19.0.2, je vois la journalisation de la console à partir de mes tests. La simple mise à jour de Jest vers la v20.0.4 (sans apporter de modifications à aucune autre configuration) entraîne la disparition de la journalisation de la console. Y a-t-il quelque chose qui me manque?

@thymikee Donc, j'ai mis à jour ma version de nœud et je ne vois aucun journal de console sur Node 8.2.1 Winx64 + Jest 20.0.4. Je dois utiliser une solution de secours pour l'instant

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

et je suis presque sûr que cela devrait être corrigé dans Jest, car les versions précédentes n'avaient pas ce problème.

@nowherenone pouvez-vous tester si cela se produit sur la dernière version alpha jest@test ?

@thymikee Juste essayé avec jest@test sur le nœud 8.2.1 mais même résultat. Les instructions console.log sont toujours avalées.

@thymikee Le problème se situe dans le module BufferedConsole, où les paramètres du constructeur de la console ne correspondent pas à ceux attendus.

J'ai ouvert un PR, peut-être que ça aiderait : https://github.com/facebook/jest/pull/4157

Je pense que le problème ici est que Jest met les messages en mémoire tampon, mais il y a quelque chose qui provoque le renflouement (ou une boucle infinie, etc.). Vous devrez utiliser --verbose pour imprimer les messages directement dans le flux de sortie.

C'est ridicule - je suis déclenché par la quantité de réponses inutiles de @cpojer (dans chaque numéro et PR auquel je vais) et j'essaie de tout mettre sur tout le monde comme si nous n'étions pas assez intelligents.

N'utilisez pas Jest - c'est ma réponse si vous vous posez la question. Trouver un nouveau cadre de test.

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

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

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

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

Je suis sûr qu'on me dira simplement d'installer une version plus récente de Node Lmao - quelle blague 😂 😂 😂

@nf071590 ne peut pas reproduire, fonctionne sur repl.it avec exactement les mêmes versions Jest et Node : https://repl.it/KYLc/0

Veuillez proposer une reproduction sérieuse avant de déclamer les mainteneurs du projet.
Acclamations!

Je ne sais pas quoi faire à ce sujet. J'ai littéralement collé votre exemple dans un fichier et exécuté Jest, et cela fonctionne comme annoncé sur mon Mac, avec la dernière version principale de Jest il y a une minute. Voir:

Jetant depuis que je suis sur Windows (nœud 8.4, jest 21.0.0-alpha.2), console.log s sont _parfois_ masqués si vous n'utilisez pas --verbose , mais semblent s'afficher de manière cohérente avec ça. Heureux de mettre à jour les résultats en utilisant le nœud 7 et la plaisanterie stable quand j'ai une minute.

Le même problème ici.

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

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

Rencontre actuellement le même problème sur le nœud v8.7.0 (npm v5.4.2).

C'est toujours un problème

Pouvez-vous fournir une reproduction?

FWIW, je me suis retrouvé ici parce que j'avais exactement le même problème. Noeud v7.4.0. J'ai mis à jour ma version de Node et console.log s'imprime comme prévu maintenant, même sans --verbose . La V7.4.0 n'est peut-être pas la seule version à avoir ce problème, mais il semble être lié à la version et non un problème pour certaines versions de Node. Je suis maintenant sur Node v8.3.0, qui semble fonctionner.

Cela dit, avant la mise à niveau, j'avais les mêmes versions que @ nf071590 et les mêmes problèmes. Je ne sais pas pourquoi cela ne se produit pas sur repl.it, mais ce n'est pas une chose étrange qui se produit uniquement sur son ordinateur.

Je peux reproduire cela avec le nœud 8.9.0 et jest 21.2.1, macOS 10.12.6 (16G1036)

@SimenB Je pourrais mais il semble que ce problème ait été discuté à mort ici et ailleurs. La nature multi-processus (enfant) de jest signifie qu'il écrasera console.logs , et sans une réécriture massive qui ne changera pas. Quiconque vient sur ce fil et souhaite éviter le problème où l'utilisation du drapeau --verbose interdit le débogage avec console.log , doit utiliser le drapeau --watch . Cela évitera l'écrasement des processus de travail enfants et vous permettra de voir une sortie détaillée avec les journaux de la console. --watch est très rapide et ajoute plus de valeur en concentrant l'attention sur les tests et le code qui ont changé, en n'exécutant que les tests qui sont modifiés lors de l'enregistrement.

Dans mon cas, j'ai trouvé que la messagerie détaillée en mangerait certains mais pas tous les messages console.log . J'ai supprimé l'option verbeuse et cela semble fonctionner un peu!

Je viens de mettre à jour ma version de nœud de v6 à v9 et l'un de mes fichiers de test est consolant.

Je me bats avec le problème depuis des semaines. Je suis content que ça marche maintenant

Le problème persiste toujours avec --verbose lorsqu'il est combiné avec --forceExit - je pense que la raison en est que console.log sort à stdout alors que jest écrit à stderr et quand --forceExit il peut encore y avoir du contenu dans stdout ne pas être vidé

J'ai trouvé la solution suivante (sans avoir besoin de --verbose ) pour corriger à la fois console.log non affiché et/ou console.log étant mis en mémoire tampon et non affiché en direct

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

contenu de jestShim.js

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

Même problème - ne jamais voir la sortie de console.log.

Node 9.80 Jest 22.4.2 Mac OS 10.13.3

Aucune des solutions de contournement suggérées ici n'a fonctionné pour moi.

Comme toujours, veuillez créer une reproduction que nous pouvons dérouler pour tester. Je n'ai pas rencontré ce problème, donc je ne sais pas par où commencer pour le résoudre

La solution de contournement de @ledbit a fonctionné pour moi
MNP 5.3.0
plaisanterie 22.4.3

• MacOS

Je suis toujours sur le point d'avoir besoin d'une reproduction.

--forceExit semble un peu cassé, mais je ne l'ai pas rencontré lorsque je n'utilise pas ce drapeau

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

J'ai finalement réussi à afficher les journaux en marquant chacun d'eux avec une chaîne de caractères particulière (par exemple, @@@ ) et en exécutant :

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

C'est un piratage terrible (vous perdez toutes les couleurs 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 essayé tout le reste 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 ).

C'est toujours un problème. J'utilise jest v22.4.3 sur Node 10.1.0 et je ne vois que la première instruction console.log de mon application, tout le reste est ignoré. Lorsque je configure ma bibliothèque de journalisation pour diffuser sur stdout, je peux voir certains des journaux, mais ils n'apparaissent pas dans le bon ordre.

Le travail de Jest en tant que testeur est de nous aider à déboguer et corriger notre code. Cela ne peut tout simplement pas être réalisé sans journaux.

@thymikee s'il vous plaît rouvrez ce problème

@thanpolas n'hésitez pas à créer un nouveau problème avec un référentiel montrant le bogue afin que nous puissions enquêter :). Veuillez également utiliser Jest 23, car c'est le dernier.

J'ai compris mon problème, la journalisation se produisait via un enregistreur qui diffusait vers stdout, lorsqu'il était redirigé vers console.log, j'ai oublié d'invoquer le rappel de l'écrivain de flux afin que le flux arrête d'envoyer des journaux.

Pour ce que ça vaut, j'ai vu des différences entre Terminal et iTerm2.

Je pense qu'une option pour demander à plaisanterie de ne pas faire de magie sur stdout et console serait très bénéfique pour tout le monde

Voici un exemple du bogue que j'ai réussi à reproduire. Je ne sais pas s'il y a plusieurs sources cependant:

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

yarn install; yarn repro

Configuration : Jest est en mode veille, avec l'indicateur détaillé activé, avec au moins deux fichiers de test en cours d'exécution.

Théorie : la sortie de l'un des travailleurs déplace le curseur de la console au mauvais endroit en écrasant le mauvais contenu.

Observation en console :

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

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

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

Watch Usage: Press w to show more.

Si je supprime le journal de la console, visuellement "RUNS" est écrasé comme prévu :

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

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

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

Watch Usage: Press w to show more.

Si j'ajoute 3 journaux de console :

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


 RUNS  tests2/other-tests.js

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

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

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

Watch Usage: Press w to show more.

Version du nœud :

30656 % node --version
v8.11.2

Je pense que @spion s'y intéresse . Belle reproduction facile.

Peut confirmer que cela se produit sur Node v8.11.1 LTS et ne se produit qu'en mode watch et watchAll . sans modes de montre, ça va.

J'ai le même problème avec Node v10.6.0 et Jest 23.4.1

Ouais moi aussi. Je viens de trouver que -w 1 fait fonctionner à nouveau la journalisation, ce qui correspond à l'hypothèse de @spion .

nœud 8.11.3
plaisanterie 23.4.0

Je rencontre ce problème, ou du moins un problème similaire, lorsque j'active la correspondance d'expression régulière de fichier (en appuyant sur p en mode watch ). Avec all activé, les journaux sont imprimés comme prévu. Remarque --verbose n'est pas ici.

Échantillon 1

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

Avec all en train de regarder (imprime à la fois log s et error s :

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

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

En mode file regex (n'imprime que les premiers log et non les error s) :

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

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

Échantillon 2

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

all (imprime à la fois log et error comme prévu) :

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

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

watch (rien n'est imprimé avec le code ci-dessus) :

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

Test Suites: 1 passed, 1 total

Échantillon 3

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

all (imprime les quatre log attendus) :

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

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

watch (seuls les deux premiers log sont imprimés avec le code ci-dessus) :

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

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

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

Test Suites: 1 passed, 1 total

Je ne suis pas sûr de ce que j'ai fait, mais je pense que l'ordre dans lequel vous configurez la plaisanterie est important. Je pense que certaines configurations peuvent s'écraser. Je reçois à la fois le test et la sortie du journal.

node -v v8.11.2
jest -v 23.4.0

Ci-dessous ma configuration de plaisanterie dans mon package.json

```
"plaisanterie": {
"transformIgnorePatterns": [
"/node_modules/"
],
"fichiers d'installation": [
"/src/setupTests.js"
],
"testEnvironment": "jsdom",
"verbeux": vrai,
"projets": [
{
"displayName": " COMPOSANTS ",
"fichiers d'installation": [
"/src/setupTests.js"
],
"modulePaths": ["/src/"],
"testMatch": ["/src/components/__tests__ / /.test.js"]},{"displayName": " RÉDUCTEURS ","fichiers d'installation": ["/src/setupTests.js"],"modulePaths": ["/src/"],"testMatch": ["/src/reducers/__tests__/ /.test.js"]
},
{
"displayName": " ACTIONS ",
"fichiers d'installation": [
"/src/setupTests.js"
],
"modulePaths": ["/src/"],
"testMatch": ["/src/actions/__tests__/ */ .test.js"]
}
]
},

Here are my dependencies

"dépendances": {
"babel-core": "^6.26.3",
"babel-jest": "^23.4.0",
"babel-loader": "^7.1.5",
"babel-preset-env": "^1.7.0",
"babel-preset-react": "^6.24.1",
"dotenv": "^6.0.0",
"express": "^4.16.3",
"plaisanterie": "^23.4.0",
"réagir": "^16.4.1",
"react-dom": "^16.4.1",
"react-redux": "^5.0.7",
"réagir-scripts": "1.1.4",
"redux": "^4.0.0",
"régénérateur-exécution": "^0.12.0"
},

output from just running jest

PASS REDUCERS src/reducers/__tests__/comments/index.test.js
✓ gère les actions de type SAVE_COMMENT (4ms)
✓ gère l'action avec un type inconnu

PASSER LES ACTIONS src/actions/__tests__/index.test.js
enregistrerCommentaire
✓ a le bon type (1ms)
✓ a la bonne charge utile (1ms)

PASSER LES COMPOSANTS src/components/__tests__/App/index.test.js
✓ Devrait afficher une liste de commentaires (5 ms)
✓ Devrait afficher une CommentBox (1ms)

PASS COMPOSANTS src/components/__tests__/CommentBox/index.test.js
✓ a une zone de texte (23ms)
✓ a un bouton (3ms)
la zone de texte
✓ a une zone de texte que les utilisateurs peuvent saisir (9 ms)
✓ lorsque le formulaire est soumis, la zone de texte est vidée (5 ms)

PASS COMPOSANTS src/components/__tests__/CommentList/index.test.js
✓ crée un LI par commentaire (32ms)

Suites de tests : 5 réussis, 5 au total
Tests : 11 réussis, 11 au total
Instantanés : 0 au total
Temps : 3,79 s
A exécuté toutes les suites de tests dans 3 projets.
console.log src/components/__tests__/CommentList/index.test.js:26
0

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

```

Ce problème devrait être rouvert, la sortie de la console avalée par la plaisanterie aussi, mon environnement est :

→ nœud --version
v8.11.3

→ plaisanterie npx --version
23.4.1

J'ai essayé avec une configuration propre et tout fonctionne bien.

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

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

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

sortir:

J'ai donc pensé que le problème pouvait être lié à ma configuration de blague:

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

Mon instinct m'a dit de vérifier verbose et après l'avoir retiré, tout va bien.

résumer

jest version 23.4.1 avec la configuration verbose définie sur true entraînerait l'avalement de la sortie de la console.

proposer de changer le flux de sortie par défaut en stdout : https://github.com/noscripter/jest/pull/1

C'est encore cassé ?! Pourquoi cela continue-t-il de casser ?

J'ai travaillé autour de cela avec:

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

😬

Si vous avez verbose: true dans votre package.json, ou si vous exécutez jest avec le drapeau --verbose (ou les deux ?), essayez de les supprimer.

Peu importe, cela n'aide plus.

Je peux souvent voir la sortie du journal pendant une fraction de seconde _avant_ que le résumé complet du test s'imprime sur la console. Je dois console.log environ 4 à 5 fois de suite pour afficher la sortie, et même dans ce cas, le dernier journal sera coupé à mi-chemin (par exemple, lors de l'impression d'un gros objet, seule la première moitié sera être visible dans le dernier journal imprimé).

C'est aussi très difficile à prévoir. Parfois, un ou deux console.log suffiront, alors que d'autres fois, je dois en mettre trois à cinq à la suite. Peu importe également si mes journaux se trouvent dans le code que je teste ou dans les cas de test eux-mêmes.

On dirait que jest imprime les journaux, puis efface la sortie avant d'imprimer le résumé complet du test, alors qu'il devrait en réalité conserver ces journaux.

J'ai accepté à ce stade que je dois copier-coller les journaux plusieurs fois pour les voir dans la console.

console.log ne fonctionne que si vous exécutez un fichier de test spécifique uniquement

yarn test <your-test-file-name>

par exemple
yarn test FormValidator

Pour info je lance ma repro avec la commande suivante :

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

C'est zsh - vous voudrez peut-être script -qfce en bash

puis j'ai consulté le journal avec cat -vet raw.log . Voici les résultats:

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

J'espère que cela t'aides. On dirait qu'il y a une erreur de comptage des codes de contrôle à un certain point.

Le résultat final ressemble à ceci :

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


 RUNS  tests2/other-tests.js

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

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

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

La ligne de la console est manquante et pass est écrit deux lignes trop bas, probablement en raison de l'entrelacement avec le console.log non pris en compte lors de la montée pour afficher le "PASS"

edit : Ajout de ce résumé dans un résumé pour faciliter la recherche et la manipulation : https://gist.github.com/spion/bbb34c5abc1230a37ad5f4f01336b8df

ps Pour reproduire cela avec le maître actuel, il faudra peut-être un peu de coercition. Lorsque vous entrez en mode montre, appuyez et maintenez "a" pendant un certain temps - les console.logs commenceront à devenir incontrôlables à un moment donné (apparaîtront à des endroits et à des moments inattendus)

Aussi j'ai oublié - je suis sur ubuntu bionic, si cela fait une différence comportement du terminal WRT:

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

Moi aussi. @spion a cloué ce que je vois. Je ne l'ai découvert que parce que j'ai des tests sur du code lent et asynchrone. Je vois la sortie de la console, puis elle est écrasée par le résumé des résultats du test.

Pour ce que ça vaut, je suis revenu à [email protected] et cela résout les problèmes que j'avais avec la sortie de résumé de test écrite sur la sortie de la console dans [email protected] .

Mise à jour - Je crois avoir trouvé un correctif minimal qui fait des progrès, mais il m'a fallu un certain temps pour comprendre l'interaction entre les reporters Jest et le générateur de statut

Jest monkey-patche les méthodes d'écriture des flux de processus stderr et stdout avec son propre écrivain. Cet écrivain écrit la sortie de jest-cli Status.js, qui contient des éléments tels que le nombre de tests en cours, une barre de progression, le temps écoulé, etc.

Chaque fois qu'il y a une instruction d'écriture sur ce flux, cette instruction est remplacée par une instruction "supprimer" pour l'état (en remontant à l'aide des codes de contrôle ANSI), l'écriture d'origine et une instruction "écrire à nouveau l'état". D'où l'illusion que le statut est toujours en bas de l'écran, alors que le texte défile au-dessus.

(Bien sûr, c'est un peu plus intelligent que cela - les écritures sont mises en mémoire tampon et les données mises en mémoire tampon ne sont réellement écrites qu'une fois toutes les 100 ms avec l'état)

Cependant, le lanceur de test parallèle (utilisé en mode veille, qui définit runInBand sur false) exécute d'autres travailleurs. Ces travailleurs sont configurés pour "hériter" du flux stdio du processus d'origine. Malheureusement, cela ne signifie pas qu'ils héritent de la version corrigée qui met à jour le statut ! Si ces écritures se produisent, elles seront

1. ajouté après le statut (le statut n'est pas effacé)
2. sera effacé lors du prochain effacement d'état (rendant l'état précédent partiellement visible aussi, puisque l'effacement ne monte pas suffisamment pour effacer à la fois la sortie de la console et l'ancienne mise à jour d'état)

Pour s'assurer que la version corrigée reçoit ces écritures tty, il est nécessaire de faire basculer les flux de processus enfants du mode "hériter" au mode "pipe". De cette façon, les sorties du processus sont disponibles sous forme de flux dans le processus enfant au lieu d'aller directement au stdout/stderr principal. Nous devons également canaliser manuellement les flux :

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

La canalisation manuelle des flux garantit que l'écriture corrigée par le singe est appelée par le nœud.

Cela casse beaucoup de tests d'intégration, mais ils sont principalement cassés en raison d'une couleur manquante. En faisant

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

réduit considérablement ce nombre, mais il reste assez élevé :

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

Je ne pense pas qu'il y ait un moyen de contourner cela - la sortie est radicalement modifiée, car beaucoup plus d'écritures finissent par ajouter la mise à jour du statut maintenant.

edit : il y a aussi le problème du vidage du flux de sortie trop tard dans certaines situations, longtemps après que le processus enfant a envoyé un message de réussite au parent.

s'il vous plaît corriger, cela nuit vraiment à la productivité avec plaisanterie

La rétrogradation vers [email protected] ramène la sortie du journal de la console. J'ai dû définir le nœud --env pour que cela fonctionne. Veuillez corriger cela.

Actuellement, il semble que la seule façon de rendre la journalisation de la console fiable est de consigner la même chose 3 à 4 fois de suite. Jest n'en bloquera qu'un certain nombre. Toujours très ennuyeux.

Y a-t-il une mise à jour à ce sujet ? J'exécute jest 23.4.1 et le nœud 9.11.1 et j'obtiens parfois la sortie du journal de la console et parfois non.

Deux ans sans journaux de console ont fait de moi un meilleur développeur. Merci à l'équipe Jest !

Je ne peux pas croire que ce soit toujours un problème. Pourquoi le sujet est-il clos ?

Je veux dire, qui voudrait jamais déboguer ses tests défaillants, n'est-ce pas ?

Comme @jonogilmour l'a mentionné, si j'enregistre quelque chose une fois qu'il ne s'affiche pas, mais que j'enregistre les choses deux fois, l'un d'entre eux s'affichera.

FWIW, la solution --verbose=false fonctionne pour moi. Dans mon package.json :

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

Quelques autres observations :

• La suppression de --env=jsdom (pas une option pour ma vraie application) l'a fait fonctionner sans --verbose=false.
• L'exécution du test directement avec plaisanterie (pas via des scripts de réaction) l'a également fait fonctionner.
• Lorsqu'une assertion échoue et que vous obtenez beaucoup plus de sortie de jest, beaucoup plus de journaux de votre console sont également écrasés.

Bonjour les gars/filles,
J'ai également rencontré le fameux problème de journalisation de la console jest lors de l'exécution des tests en mode --watch.
La solution consistait à utiliser --watchAll au lieu de --watch. Le résumé des tests est devenu plus laid, mais les journaux se sont affichés comme prévu.

macOS High Sierra
nœud v8.11.3
plaisanterie : 23.6.0
ts-jest : 23.10.4

Pour moi c'est en beforeAll

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

et ceci dans le shell a fait le travail:

yarn test > test.log

Pour moi, passer à mocha a résolu le problème. Il est très trivial de basculer, puisque le DSL est très similaire. Vous pouvez même continuer à utiliser la bibliothèque attendue de JEST : https://www.npmjs.com/package/expect

C'est presque aussi simple que de supprimer jest et d'installer mocha .

Edit : Spam ou pas, c'est la solution la plus simple ici.

Ce problème fait vraiment mal, j'aimerais que les responsables puissent résoudre ce problème dès que possible, car Jest est destiné à augmenter la productivité, et non l'inverse, n'est-ce pas ?

Quoi qu'il en soit, voici ce que j'utilise en écriture maintenant:

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

Tu dois spammer ta sortie.

Confirmé que --verbose=false résout le problème.

--verbose=false ne fonctionne pas pour moi avec la version 23.6.0

OMG c'est une douleur :/ novembre 2018

Veuillez rouvrir ce problème

essayez de définir silent: false dans jest.config.js ... dans mon cas, cela m'a aidé

Aucune des solutions ne fonctionne.
NodeJS : v8.12.0
Plaisanterie : v23.4.1

J'utilise Jest depuis des mois et c'est génial et bien que ce bogue soit _super ennuyeux_ , la solution de contournement que j'ai toujours utilisée est de faire une affirmation indésirable car cela se connectera à la console à chaque fois.

Exemple, lorsque vous essayez de vous déconnecter d'un appel fictif :

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

Ce n'est pas l'idéal mais cela fait le travail et me permet de finir d'écrire mes tests.

Lancer Jest avec un indicateur --watch.
Blague version 23.5.0
Version de nœud 8.11.3

C'est un exemple décent de "trop ​​​​de magie" qui se passe sous le capot, et des conséquences de cela quand quelque chose ne va pas. Je ne suis pas convaincu que le regroupement de la sortie console.log vaut un an et demi d'instructions console.log manquantes. 😕

D'accord avec ce qui précède - ce n'est pas tout à fait un obstacle, mais cela rend Jest douloureux d'une manière totalement inutile.

Ma "solution de contournement" est qu'une grande partie de la logique utilise log4js , donc pour l'endroit où je plie Jest au code côté serveur, je suis bon. Malheureusement, j'ai une grande quantité de code côté client où je copie et colle habituellement quatre copies de chaque console.log car finalement l'un d'eux semble apparaître.

L'utilisation expect pour enregistrer les informations est une solution de contournement acceptable si vous vous connectez à partir d'un test (d'autant plus que vous pouvez créer un extrait avec un mot-clé comme logjest dans votre éditeur), mais cela échoue chaque fois que vous avez besoin de creuser plus profondément et de vous connecter à partir des fonctions réelles que vos tests appellent.

Que diriez-vous CI=true yarn run test ?

Désolé pour ce que j'ai dit auparavant, mais cela fonctionne bien sans le titre des cas de test, je veux dire, sans l'option "--verbose", je pense que --verbose fait une sorte de formatage et remplace le flux stdout.
Donc, pour moi, j'ai été comme 2 mois et tout fonctionne bien.
Et si quelqu'un veut utiliser cette option, ajoutez-la uniquement à vos commandes npm comme suit : npm run test:integration ---watchAll --verbose --coverage --etc

Les personnes ayant le problème peuvent-elles tester [email protected] ? Il comprend #6871

@ jamesta696 Salut, je pense que vous devez poster ce genre de questions sur StackOverflow en utilisant la balise "jest" ici parce que les discussions ici concernent des "problèmes", néanmoins, je sais que quelqu'un pourrait vous aider, mais le problème ici pourrait être fermé parce que la question principale n'est pas discutée.
Et pour l'instant, je ne peux pas vous donner de réponse à cette question parce que je ne développe pas quelque chose pour réagir et le frontend, aussi, je ne suis pas membre de jest, mais essayons de suivre les règles.

@SimenB J'ai mis à jour la plaisanterie (vers votre version mentionnée) et j'ai essayé de placer quelques instructions console.log dans mon projet qui avaient le problème. Jusqu'à présent, cela semble être corrigé : tous les console.log s'affichent. Je continuerai à l'utiliser et je vous tiendrai au courant si je rencontre à nouveau le problème.

Pour info : j'utilisais (et j'utilise toujours) jest --watchAll

@tobyhinloopen Cool de voir une preuve des progrès qui mentionnaient @SimenB .

c'est génial @tobyhinloopen !

Je peux également confirmer que [email protected] fonctionne correctement et que vous pouvez voir tous les journaux de la console sans --verbose=false.

Je peux également confirmer que [email protected] fonctionne correctement et que vous pouvez voir tous les journaux de la console sans --verbose=false.

+1. peut également confirmer. content de voir que cela fonctionne. beau travail, les gens de Jest ! 😄

je confirme aussi ! C'est comme Noël. 🎅

😃

juste besoin de ne pas attendre les mises à jour de create-react-app

J'utilise la version blague 24.0.0 , mais je ne vois toujours pas console.log ou console.error . Je me demande ce que je fais de mal.

Assurez-vous qu'ils ne sont pas moqués

C'est vraiment bizarre. Il semble y avoir un problème avec la gestion asynchrone. Je n'arrive pas à afficher les erreurs. Même s'il est enveloppé dans des blocs try/catch , je ne vois pas l'erreur.

Le paramètre generator est correct à coup sûr, si je supprime l'appel de fonction asynchrone, il se connecte correctement. Il renvoie également la chaîne correcte lorsqu'elle se trouve en dehors de la boucle for.

La version de plaisanterie est 24.0.0 , le nœud est 10.5

@tiborsaas Votre test sera probablement terminé avant l'exécution console.log .
Si vous voulez attendre l'itération sur changedGenerators , vous aurez besoin de quelque chose comme

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

Merci pour la réponse, mais ce n'est pas vraiment le cas, une erreur empêche l'affichage du console.log . Il existe une autre fonction asynchrone qui fonctionne bien avec console.log si je l'appelle dans le rappel forEach .

Edit: en fait, par débogage ligne par ligne, je sais que le problème vient de

const archives = await fs.readdir(archiveDir);

Cependant, ce problème de plaisanterie concerne la journalisation des choses. Je ne veux pas faire dérailler la conversation.

Vous rencontrez peut-être encore un bogue, je voulais juste souligner (sans connaître votre code exact) que c'est généralement une mauvaise idée en général de forger un tas de promesses comme celle-ci sans les attendre, car elles pourraient rejeter une fois votre test terminé : )

Je suis d'accord, mais je veux exécuter les appels expect dans le forEach parce que je ne sais pas à l'avance combien de changements je dois gérer.

Malheureusement, l'approche Promise.all n'a rien résolu.

Avez-vous utilisé map au lieu de forEach ? Le but est de retourner un tableau de promesses à Promise.all

@SimenB oui, je sais.

S'il y a une erreur, je ne la vois pas.

@tiborsaas Vous n'attendez pas que Promise.all se termine : utilisez await Promise.all(...)

J'ai fait ça aussi, même résultat. :(

et si vous ajoutiez await new Promise((resolve) => setTimeout(resolve, 1000)) sous votre promise.all ?

Pouvez-vous ouvrir un nouveau numéro avec une reproduction ? Je crois que le problème signalé par l'OP est résolu pendant que vous en voyez un autre (peu importe si vous gérez correctement l'asynchronisme ou non, vous devriez toujours voir l'instruction de journal)

Ouais c'est étrange en effet, quelque chose comme

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

est généralement encore imprimé d'une manière ou d'une autre

Il utilise une fonction de rappel comme 2ème argument de Promise.all([...], callback) . Il devrait utiliser Promise.all([...]).then(callback) . Peut-être que cela résout son problème, je pense que le 2ème argument de .all est ignoré et jamais exécuté (donc vos journaux ne seront jamais exécutés). @tiborsaas

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

Oui, c'est faux, mais les instructions de journal doivent toujours apparaître

@SimenB Non, le 2ème argument est ignoré.

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

Ouais, j'ai confondu avec ça, désolé. Merci @tobyhinloopen

const lol = await Promise.all(versions); a fonctionné comme prévu.

Dans ce cas, les instructions de journal peuvent être perdues car la fonction n'est jamais appelée, mais vous devriez toujours voir les instructions de journal dans le cas d'origine forEach puisque le nœud attendra que les promesses se terminent avant de quitter le processus. C'est donc toujours un bug, même s'il s'agit d'une erreur de l'utilisateur

CP : # 7731

J'utilise https://www.npmjs.com/package/debug pour faire la journalisation. Est-ce que ça marcherait avec Jest ?

Non, pas avant d'avoir fait #6524.

Je recommanderais de vous moquer debug dans vos tests et d'utiliser console.log si vous voulez les voir

Pour référence, les messages de la console peuvent être perdus s'ils sont imprimés après la fin des tests, voir les commentaires au bas de #7731. Cela pourrait être la raison pour certains, mais probablement pas pour tous les messages de console manquants signalés ici.

Le --verbose a fonctionné pour moi. Avant d'utiliser --verbose, certains messages, mais pas tous, étaient perdus. J'utilise node v10.15.3 et jest v21.2.1

Toujours un problème pour moi, les journaux de la console ne s'affichent pas dans Jest

malgré la dernière annonce dans le blog que le problème a finalement été résolu, le problème existe toujours, mes journaux de console ne s'affichent parfois plus, j'utilise jest v24.8.0 .

Et mes œuvres très bien 🤷‍♂️. S'il vous plaît poster une reproduction que nous pouvons enquêter. Nous ne sommes pas des assistants, nous ne pouvons pas voir votre code qui ne parvient pas à enregistrer la sortie.

en fait, après enquête, les journaux liés aux tests d'API (comme le supertest) ne fonctionnent pas. attendu :/

@thymikee Cela se produit de manière incohérente, il est donc très difficile de le reproduire. Exemple:
exécutions suivantes en sélectionnant un seul fichier parmi les tests (option p)

• console.log('pantz') (fonctionne)
• changer console.log(myObject) (ne fonctionne pas)
• changez-le pour l'adapter (ne fonctionne pas)
• passer à console.log('pantz') (ne fonctionne pas)
• changer d'ajustement (ne fonctionne pas)
• redémarrer jest (ne fonctionne pas)
• changez-le pour l'adapter (travail)

Maintenant, j'ai essayé de reproduire les mêmes étapes et le résultat est incohérent.

Fournissez un exemple de référentiel là où cela ne fonctionne pas afin que les gars de JEST puissent aider à le déboguer. @kresli

Il existe également de nombreuses possibilités d'erreurs d'utilisateur, la plupart du temps des await manquants ou des $#$1 console.log #$ asynchrones.

Je vais essayer de trouver un moment pour reproduire cela alors. Jusque-là, j'ai trouvé que mes journaux étaient mangés par les résultats, comme vous pouvez le voir ci-dessous. Avant que FAIL n'apparaisse, vous pouvez y voir mes 2 journaux. Et aussi sa valeur de mentionner que seulement 2 journaux sont supprimés. Si j'ajoute 10 journaux les uns sous les autres, 8 seront affichés. Je pense que c'est un bon début :)

En attendant, si vous avez besoin d'un correctif fourre-tout qui fonctionne, vous pouvez utiliser quelque chose comme winston pour vous connecter à la fois au fichier et à la console. Même si vos messages de console ne s'affichent pas, ils sont écrits dans un fichier.

Avec winston , vous pouvez configurer ce que vous voulez enregistrer où et il prend en charge plusieurs transports, et les transports que vous pouvez implémenter vous-même.

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

logger.error(stuff)

Peut-être que vous pouvez même faire quelque chose de sale comme remplacer console.* globalement par l'enregistreur de Winston.

@kresli quelle version est votre blague? Cela ressemble au comportement v23

Cela m'arrive sans cesse avec jest v^24.6.0 et node v10.14.2 . Une idée pourquoi?

@yaelz Il s'agit d'un problème persistant qui est généralement causé par une erreur de l'utilisateur, mais qui a également un historique de bogues difficiles à reproduire.

Je pense que cela aiderait vraiment les contributeurs à fournir un cas reproductible en fournissant un exemple de référentiel ou en fournissant un autre moyen de reproduire le problème.

Merci pour la réponse rapide!
Ce sera difficile car le dépôt actuel est privé dans mon organisation... Je vous ferai savoir si j'y arrive :)

Cela m'arrive sans cesse avec jest v^24.6.0 et node v10.14.2 . Une idée pourquoi?

J'ai récemment mis à jour certaines dépendances dans un projet et je n'ai aucun problème, j'y ai fait face il y a un mois, mais cela a été résolu dans les versions plus récentes, je crois...

Pouvez-vous s'il vous plaît partager les versions que vous utilisez maintenant, une fois résolues ?

Le lun. 5 août 2019 à 12 h 43 Norman Enmanuel [email protected]
a écrit:

Merci pour la réponse rapide!
Ce sera difficile car le dépôt actuel est privé dans mon organisation... Je vais laisser
tu sais si j'y arrive :)

J'ai récemment mis à jour certaines dépendances dans un projet et je n'en ai pas
problème, j'y ai fait face il y a un mois, mais j'ai été résolu dans les versions plus récentes que j'ai
croyez...

—
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/3853?email_source=notifications&email_token=AB6F4PAE3CHUMEBP7IYXRPLQC7Y2DA5CNFSM4DPZ3JSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3RI3PY#issuecomment-5PY1
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AB6F4PFXDSRHBW5CMTT2DKDQC7Y2DANCNFSM4DPZ3JSA
.

Pouvez-vous s'il vous plaît partager les versions que vous utilisez maintenant, une fois résolues ?

Sûr:

plaisanter

^24.8.0

nœud -v

v10.16.0

Et voici quelques scripts npm que j'utilise pour exécuter à la fois e2e, intégration, unité et acceptation :

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

Voici le jest.config :

"use strict";

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

J'espère que ça aide.

Je vais essayer de trouver un moment pour reproduire cela alors. Jusque-là, j'ai trouvé que mes journaux étaient mangés par les résultats, comme vous pouvez le voir ci-dessous. Avant que FAIL n'apparaisse, vous pouvez y voir mes 2 journaux. Et aussi sa valeur de mentionner que seulement 2 journaux sont supprimés. Si j'ajoute 10 journaux les uns sous les autres, 8 seront affichés. Je pense que c'est un bon début :)

@kresli Quelle est la barre d'état et la sortie de l'heure que vous avez ici ? Lorsque j'exécute ma suite de tests, je vois _RUN HARNESS test-harness/index.js_ et rien d'autre jusqu'à ce que tout fonctionne. Je vois alors mon message console.log à la toute fin et la ligne avec _RUN HARNESS..._ change en _HARNAIS...._

Mise à jour: veuillez ignorer, s'est avéré être un problème dans mon code

Toujours face à cela avec le nœud v12.16.1, jest 25.5.4, tapuscrit 3.8.3 sur MacOS. J'ai essayé les recommandations d'utilisation de --runInBand, de désactivation/activation de verbose, d'utilisation de --silent=true, cela n'a pas aidé.