@thymikee Irgendeine Idee, warum das passiert?

Keine Ahnung, aber ich würde versuchen, das Beispiel zu minimieren, zB durch Entfernen von Typoskript

Ich kann ohne Typescript reproduzieren

Kann bestätigen, dass Node 7.4 Konsolenprotokolle frisst, aber es funktioniert auf Node 7.5.0, 7.10.0, 8.0.0 und 8.1.2.
Bitte aktualisieren Sie Ihre Node-Version. Schließen

@thymikee Was ist mit Node 6, der aktuellen LTS-Version? (Sieht so aus, als ob ich das auch treffe, obwohl ich es noch nicht genug debuggt habe. Ich bin jedoch vorerst auf LTS-Versionen beschränkt, kann also kein Upgrade durchführen).

Getestet auf v6.11.0, zeigt immer noch console.log s.

Ah, ich könnte auf ein anderes Problem stoßen. Danke, @thymikee , ich gehe zurück zum Debuggen ein bisschen mehr.

Ich habe Node 7.3.0 unwissentlich ausgeführt (falsche Version über n) und es wurde nicht protokolliert. Wechselte zu 8.1.1 und es wurde erneut geloggt.

@thymikee - Ich verstehe nicht, wie das die Lösung ist? ...Ich kann meine Knotenversion nicht aktualisieren

Ich denke, ich bin ein wenig verwirrt, wie dies als Node-Bug angesehen werden könnte und nicht zumindest etwas mit Jest selbst zu tun hat. Bei Verwendung von Node v7.4.0 mit Jest v19.0.2 sehe ich die Konsolenprotokollierung meiner Tests. Durch einfaches Aktualisieren von Jest auf v20.0.4 (ohne Änderungen an einer anderen Konfiguration vorzunehmen) wird die Konsolenprotokollierung nicht mehr angezeigt. Gibt es etwas, das ich vermisse?

@thymikee Also, ich habe meine Node-Version aktualisiert und sehe keine Konsolenprotokolle auf Node 8.2.1 Winx64 + Jest 20.0.4. Ich muss jetzt einen Fallback verwenden

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

und ich bin mir ziemlich sicher, dass es in Jest behoben werden sollte, da frühere Versionen dieses Problem nicht hatten.

@nowhereenone kannst du testen, ob es bei der neuesten Alpha-Version jest@test passiert?

@thymikee Habe es gerade mit jest@test auf dem Knoten 8.2.1 versucht, aber das gleiche Ergebnis. console.log -Anweisungen werden immer geschluckt.

@thymikee Das Problem liegt im BufferedConsole-Modul, wo die Konstruktorparameter der Konsole nicht mit den erwarteten übereinstimmen.

Ich habe eine PR geöffnet, vielleicht hilft es: https://github.com/facebook/jest/pull/4157

Ich denke, das Problem hier ist, dass Jest Nachrichten puffert, aber es gibt etwas, das zum Aussteigen führt (oder eine Endlosschleife usw.). Sie müssen --verbose verwenden, um die Nachrichten direkt in den Ausgabestream zu drucken.

Das ist lächerlich – ich werde durch die Menge an nutzlosen Antworten von @cpojer (in jeder Ausgabe und PR, zu der ich gehe) und dem Versuch, alles auf alle anderen zu schieben, ausgelöst, als wären wir irgendwie nicht schlau genug.

Verwenden Sie Jest nicht - das ist meine Antwort, wenn Sie sich fragen. Finden Sie ein neues Testframework.

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

Ich bin mir sicher, dass ich nur aufgefordert werde, eine neuere Version von Node Lmao zu installieren - was für ein Witz 😂 😂 😂

@nf071590 kann nicht reproduzieren, funktioniert auf repl.it mit genau denselben Jest- und Node-Versionen: https://repl.it/KYLc/0

Bitte denken Sie sich eine ernsthafte Repro aus, bevor Sie über Projektbetreuer schimpfen.
Prost!

Ich bin mir nicht sicher, was ich dagegen tun soll. Ich habe Ihr Beispiel buchstäblich in eine Datei eingefügt und Jest ausgeführt, und es funktioniert wie angekündigt auf meinem Mac, mit der neuesten Master-Version von Jest seit einer Minute. Sehen:

Da ich Windows verwende (Knoten 8.4, nur 21.0.0-alpha.2), sind console.log s _manchmal_ ausgeblendet, wenn Sie --verbose nicht verwenden, scheinen aber konsistent zu sein damit. Ich freue mich, die Ergebnisse mit Knoten 7 und stabilem Scherz zu aktualisieren, wenn ich eine Minute Zeit habe.

Hier das gleiche Problem.

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

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

Derzeit tritt dasselbe Problem auf Knoten v8.7.0 (npm v5.4.2) auf.

Dies ist immer noch ein Problem

Können Sie eine Reproduktion zur Verfügung stellen?

FWIW, ich bin hier gelandet, weil ich genau das gleiche Problem hatte. Knoten v7.4.0. Ich habe meine Node-Version aktualisiert und console.log wird jetzt wie erwartet gedruckt, auch ohne --verbose . V7.4.0 ist möglicherweise nicht die einzige Version, bei der dieses Problem auftritt, aber es scheint mit der Version zusammenzuhängen und bei einigen Node-Versionen kein Problem zu sein. Ich bin jetzt auf Node v8.3.0, was zu funktionieren scheint.

Allerdings hatte ich vor dem Upgrade die gleichen Versionen wie @nf071590 und die gleichen Probleme. Ich bin mir nicht sicher, warum es nicht auf repl.it passiert, aber es ist keine seltsame Sache, die nur auf seinem Computer passiert.

Ich kann dies mit Knoten 8.9.0 und jest 21.2.1, macOS 10.12.6 (16G1036) reproduzieren

@SimenB Ich könnte, aber es sieht so aus, als ob dieses Problem hier und anderswo zu Tode diskutiert wurde. Die Natur von jest mit mehreren (untergeordneten) Prozessen bedeutet, dass console.logs überschrieben wird, und ohne massives Umschreiben wird sich das nicht ändern. Jeder, der zu diesem Thread kommt und das Problem vermeiden möchte, dass die Verwendung des Flags --verbose das Debuggen mit console.log verbietet, sollte das Flag --watch verwenden. Dadurch wird verhindert, dass die untergeordneten Worker-Prozesse überschrieben werden, und Sie können eine ausführliche Ausgabe mit Konsolenprotokollen sehen. --watch ist sehr schnell und bringt mehr Wert, indem es die Aufmerksamkeit auf die Tests und den Code lenkt, die sich geändert haben, indem nur die Tests ausgeführt werden, die beim Speichern geändert wurden.

In meinem Fall fand ich heraus, dass die ausführliche Nachricht einige, aber nicht alle console.log -Nachrichten verschlingen würde. Ich habe die ausführliche Option entfernt und es scheint etwas zu funktionieren!

Ich habe gerade meine Knotenversion von v6 auf v9 aktualisiert und eine meiner Testdateien tröstet mich.

Ich kämpfe seit Wochen mit dem Problem. Ich bin froh, dass es jetzt funktioniert

Das Problem besteht weiterhin mit --verbose in Kombination mit --forceExit - ich denke, der Grund dafür ist, dass console.log in stdout ausgegeben wird, während Jest in stderr schreibt --forceExit noch Inhalt in stdout vorhanden ist, kann dieser nicht geleert werden

Ich habe die folgende Lösung gefunden (ohne die Notwendigkeit von --verbose ), um zu beheben, dass sowohl console.log nicht angezeigt wird als auch console.log gepuffert und nicht live angezeigt wird

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

Inhalt von jestShim.js

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

Dasselbe Problem - sehen Sie niemals die Ausgabe von console.log.

Node 9.80 Jest 22.4.2 Mac OS 10.13.3

Keine der hier vorgeschlagenen Problemumgehungen hat bei mir funktioniert.

Erstellen Sie bitte wie immer eine Reproduktion, die wir zum Testen herunterziehen können. Ich habe dieses Problem nicht festgestellt, daher bin ich mir nicht sicher, wie ich mit der Behebung beginnen soll

Workaround von @ledbit hat bei mir funktioniert
NPM 5.3.0
Spaß 22.4.3

• Mac OS

Ich bin immer noch an dem Punkt, an dem ich eine Reproduktion brauche.

--forceExit scheint etwas kaputt zu sein, aber ich bin nicht darauf gestoßen, wenn ich dieses Flag nicht verwende

[Verwendung react-scripts Fork zur Verwendung des neuesten Jest v23.0.0, Knoten v8.11.2]

Ich habe endlich die Protokolle angezeigt, indem ich sie mit einer bestimmten Zeichenfolge (z. B. @@@ ) markiert und ausgeführt habe:

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

Es ist ein schrecklicher Hack (Sie verlieren alle Konsolenfarben, aber Sie sehen immer noch Testfehler und eine endgültige Testzusammenfassung), aber es ist das einzige, was bisher funktioniert hat. Ich habe alles andere in den Kommentaren oben versucht. Beachten Sie, dass das --verbose für diese Lösung erforderlich ist (und über react-scripts implizit mit --watch kombiniert wird).

Dies ist immer noch ein Problem. Ich verwende Jest v22.4.3 auf Node 10.1.0 und sehe nur die erste console.log-Anweisung meiner App, alle anderen werden ignoriert. Wenn ich meine Protokollierungsbibliothek so einstelle, dass sie auf stdout streamt, kann ich einige der Protokolle sehen, aber sie werden nicht in der richtigen Reihenfolge angezeigt.

Jests Aufgabe als Testrunner ist es, uns beim Debuggen und Korrigieren unseres Codes zu helfen. Ohne Protokolle geht das einfach nicht.

@thymikee Bitte öffnen Sie dieses Problem erneut

@thanpolas Fühlen Sie sich frei, ein neues Problem mit einem Repository zu erstellen, das den Fehler zeigt, damit wir ihn untersuchen können :). Bitte verwenden Sie außerdem Jest 23, da dies das neueste ist.

Ich habe mein Problem herausgefunden, die Protokollierung erfolgte über einen Logger, der nach stdout gestreamt wurde. Als ich zu console.log umgeleitet wurde, habe ich vergessen, den Rückruf des Stream-Writers aufzurufen, sodass der Stream aufhörte, Protokolle zu senden.

Für das, was es wert ist, habe ich Unterschiede zwischen Terminal und iTerm2 gesehen.

Ich denke, eine Option, Jest anzuweisen, auf stdout und Konsole nicht zu zaubern, wäre für alle sehr vorteilhaft

Hier ist eine Instanz des Fehlers, die ich reproduzieren konnte. Ich bin mir aber nicht sicher, ob es mehrere Quellen gibt:

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

yarn install; yarn repro

Setup: Jest befindet sich im Watch-Modus, mit eingeschaltetem Verbose-Flag und mindestens zwei laufenden Testdateien.

Theorie: Die Ausgabe von einem der Worker bewegt den Konsolencursor an die falsche Stelle und überschreibt den falschen Inhalt.

Beobachtung in der Konsole:

 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.

Wenn ich das Konsolenprotokoll entferne, wird visuell "RUNS" wie beabsichtigt überschrieben:

 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.

Wenn ich 3 Konsolenprotokolle hinzufüge:

 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.

Knotenversion:

30656 % node --version
v8.11.2

Ich denke, @spion arbeitet daran. Schöne einfache Repro.

Kann bestätigen, dass dies auf Node v8.11.1 LTS passiert und nur im watch - und watchAll -Modus passiert. ohne Uhrmodi, es ist in Ordnung.

Ich habe das gleiche Problem mit Node v10.6.0 und Jest 23.4.1

Ja ich auch. Ich habe gerade festgestellt, dass -w 1 die Protokollierung wieder zum Laufen bringt, was zu @spions Hypothese passt.

Knoten 8.11.3
Scherz 23.4.0

Ich finde dieses Problem oder zumindest ein ähnliches Problem, wenn ich den Datei-Regex-Abgleich einschalte (durch Drücken p im watch -Modus). Wenn all aktiviert ist, werden die Protokolle wie erwartet gedruckt. Beachten Sie, dass --verbose hier nicht aktiviert ist.

Probe 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');
    ...

Während all zusieht (druckt sowohl log s als auch 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

Im Modus file regex (druckt nur die ersten log und nicht die 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

Probe 2

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

all (gibt wie erwartet sowohl log als auch error aus):

 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 (mit obigem Code wird nichts gedruckt):

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

Probe 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 (druckt alle vier erwarteten log s):

 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 (nur die ersten beiden log s werden mit obigem Code gedruckt):

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

Ich bin mir nicht sicher, was ich getan habe, aber ich denke, die Reihenfolge, wie Sie Witze einrichten, ist wichtig. Ich denke, einige Konfigurationen können sich gegenseitig überschreiben. Ich bekomme sowohl die Test- als auch die Protokollausgabe.

node -v v8.11.2
jest -v 23.4.0

Unten ist meine Scherzkonfiguration in meiner package.json

```
"Scherz": {
"transformIgnorePatterns": [
"/node_modules/"
],
"setupFiles": [
"/src/setupTests.js"
],
"testEnvironment": "jsdom",
"verbose": wahr,
"Projekte": [
{
"displayName": " KOMPONENTEN ",
"setupFiles": [
"/src/setupTests.js"
],
"Modulpfade": ["/src/"],
"testMatch": ["/src/components/__tests__/ / .test.js"]},{"displayName": " REDUZIERER ","setupFiles": ["/src/setupTests.js"],"Modulpfade": ["/src/"],"testMatch": ["/src/reduzierer/__tests__/ /.test.js"]
},
{
"displayName": " AKTIONEN ",
"setupFiles": [
"/src/setupTests.js"
],
"Modulpfade": ["/src/"],
"testMatch": ["/src/actions/__tests__/ */ .test.js"]
}
]
},

Here are my dependencies

"Abhängigkeiten": {
"babel-core": "^6.26.3",
"babel-scherz": "^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",
"Scherz": "^23.4.0",
"reagieren": "^16.4.1",
"react-dom": "^16.4.1",
"react-redux": "^5.0.7",
"Reaktionsskripte": "1.1.4",
"redux": "^4.0.0",
"regenerator-runtime": "^0.12.0"
},

output from just running jest

PASS REDUCERS src/reducers/__tests__/comments/index.test.js
✓ behandelt Aktionen vom Typ SAVE_COMMENT (4ms)
✓ verarbeitet Aktionen mit unbekanntem Typ

AKTIONEN BESTANDEN src/actions/__tests__/index.test.js
saveComment
✓ hat den richtigen Typ (1ms)
✓ hat die richtige Payload (1ms)

KOMPONENTEN BESTANDEN src/components/__tests__/App/index.test.js
✓ Sollte eine Kommentarliste anzeigen (5ms)
✓ Sollte eine CommentBox anzeigen (1ms)

BESTANDEN KOMPONENTEN src/components/__tests__/CommentBox/index.test.js
✓ hat einen Textbereich (23ms)
✓ hat eine Taste (3ms)
den Textbereich
✓ hat einen Textbereich, den Benutzer eingeben können (9ms)
✓ Wenn das Formular gesendet wird, wird der Textbereich geleert (5 ms)

KOMPONENTEN BESTANDEN src/components/__tests__/CommentList/index.test.js
✓ erstellt einen LI pro Kommentar (32ms)

Test Suites: 5 bestanden, 5 insgesamt
Tests: 11 bestanden, 11 insgesamt
Schnappschüsse: 0 insgesamt
Zeit: 3,79 s
Alle Testsuiten in 3 Projekten ausgeführt.
console.log src/components/__tests__/CommentList/index.test.js:26
0

console.log src/components/__tests__/CommentList/index.test.js:27
Prüfen

```

Dieses Problem sollte wieder geöffnet werden, Konsolenausgabe auch von Scherz geschluckt, meine Umgebung ist:

→ Knoten --Version
v8.11.3

→ npx jest --version
23.4.1

Ich habe es mit einem sauberen Setup versucht und alles funktioniert gut.

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

Ausgang:

Also dachte ich, das Problem könnte mit meiner Jest-Konfiguration zusammenhängen:

{
  "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"
  }
}

Mein Instinkt sagte mir, ich solle verbose überprüfen und nach dem Entfernen ist alles in Ordnung.

rekapitulieren

Jest-Version 23.4.1 mit der Konfiguration verbose auf true würde dazu führen, dass die Konsolenausgabe geschluckt wird.

schlagen vor, den Standardausgabestream in stdout zu ändern: https://github.com/noscripter/jest/pull/1

Schon wieder kaputt?! Warum geht das immer wieder kaputt?

Ich habe das umgangen mit:

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

😬

Wenn Sie verbose: true in Ihrer package.json haben oder Sie Scherz mit dem Flag --verbose (oder beides?) ausführen, versuchen Sie, sie zu entfernen.

Egal, das hilft nicht mehr.

Ich kann die Protokollausgabe oft für den Bruchteil einer Sekunde sehen, _bevor_ die vollständige Testzusammenfassung auf der Konsole gedruckt wird. Ich muss ungefähr 4-5 Mal hintereinander console.log drücken, damit die Ausgabe angezeigt wird, und selbst dann wird das letzte Protokoll auf halbem Weg abgeschnitten (zum Beispiel beim Drucken eines großen Objekts wird nur die erste Hälfte im letzten gedruckten Protokoll sichtbar sein).

Es ist auch sehr schwer vorherzusagen. Manchmal reichen ein oder zwei console.log s, während ich manchmal drei bis fünf hintereinander setzen muss. Es spielt auch keine Rolle, ob sich meine Protokolle in dem Code befinden, den ich teste, oder in den Testfällen selbst.

Anscheinend druckt Scherz die Protokolle und löscht dann die Ausgabe, bevor die vollständige Testzusammenfassung gedruckt wird, obwohl diese Protokolle eigentlich aufbewahrt werden sollten.

Ich habe an dieser Stelle akzeptiert, dass ich die Protokolle mehrmals kopieren und einfügen muss, um sie in der Konsole anzuzeigen.

console.log funktioniert nur, wenn Sie eine bestimmte Testdatei ausführen

yarn test <your-test-file-name>

z.B
yarn test FormValidator

FYI Ich führe meine Repro mit dem folgenden Befehl aus:

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

Das ist zsh - vielleicht möchten Sie script -qfce in bash

und dann habe ich das Protokoll mit cat -vet raw.log angesehen. Hier sind die Ergebnisse:

^[[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$

Hoffe das hilft. Anscheinend gibt es an einem bestimmten Punkt eine Fehlzählung der Steuercodes.

Das Endergebnis sieht so aus:

 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.

Die Konsolenzeile fehlt, und pass ist zwei Zeilen zu weit unten geschrieben, wahrscheinlich aufgrund der Verflechtung mit der Datei console.log, die nicht berücksichtigt wird, wenn nach oben gegangen wird, um "PASS" anzuzeigen.

Bearbeiten: Diese Zusammenfassung wurde zur einfachen Suche und Bearbeitung in einem Gist hinzugefügt: https://gist.github.com/spion/bbb34c5abc1230a37ad5f4f01336b8df

ps Um dies mit dem aktuellen Master zu reproduzieren, ist möglicherweise etwas Zwang erforderlich. Wenn Sie in den Watch-Modus wechseln, halten Sie "a" eine Weile gedrückt - die console.logs beginnen irgendwann außer Kontrolle zu geraten (erscheinen an unerwarteten Orten und zu unerwarteten Zeiten).

Ich habe auch vergessen - ich bin auf Ubuntu Bionic, wenn das einen Unterschied macht WRT-Terminalverhalten:

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

Ich auch. @spion hat genau das getroffen, was ich sehe. Ich habe es nur entdeckt, weil ich Tests mit langsamem, asynchronem Code durchgeführt habe. Ich sehe eine Konsolenausgabe, dann wird sie durch die Zusammenfassung der Testergebnisse überschrieben.

Für das, was es wert ist, bin ich zu [email protected] zurückgekehrt und behebe damit die Probleme, die ich hatte, als die Ausgabe der Testzusammenfassung über die Konsolenausgabe in [email protected] geschrieben wurde.

Update - Ich glaube, ich habe einen minimalen Patch gefunden, der einige Fortschritte macht, aber es hat eine Weile gedauert, bis ich die Interaktion zwischen Jest-Reportern und dem Statusgenerator verstanden habe

Jest Monkey patcht die Schreibmethoden der Prozess-stderr- und stdout-Streams mit seinem eigenen Writer. Dieser Writer schreibt die Ausgabe von jest-cli Status.js auf, die Dinge wie die Anzahl der laufenden Tests, einen Fortschrittsbalken, die verstrichene Zeit und so weiter enthält.

Immer wenn es eine Schreibanweisung in diesem Strom gibt, wird diese Anweisung durch eine "Lösch"-Anweisung für den Status (aufsteigend unter Verwendung von ANSI-Steuercodes), das ursprüngliche Schreiben und eine "Schreibe den Status erneut"-Anweisung ersetzt. Daher die Illusion, dass der Status immer am unteren Rand des Bildschirms angezeigt wird, während der Text darüber scrollt.

(Natürlich ist es ein bisschen schlauer als das - die Schreibvorgänge werden gepuffert und die gepufferten Daten werden nur alle 100 ms zusammen mit dem Status wirklich einmal geschrieben.)

Der parallele Test-Runner (im Überwachungsmodus verwendet, der runInBand auf false setzt) ​​führt jedoch andere Worker aus. Diese Worker sind so eingerichtet, dass sie den Stdio-Stream des ursprünglichen Prozesses „erben“. Leider bedeutet das nicht, dass sie die gepatchte Version erben, die den Status aktualisiert! Wenn diese Schreibvorgänge passieren, werden sie es sein

1. nach dem Status hinzugefügt (der Status wird nicht gelöscht)
2. wird beim nächsten Statuslöschen gelöscht (wodurch der vorherige Status auch teilweise sichtbar wird, da das Löschen nicht weit genug nach oben geht, um sowohl die Konsolenausgabe als auch die alte Statusaktualisierung zu löschen)

Um sicherzustellen, dass die gepatchte Version diese tty-Schreibvorgänge erhält, ist es notwendig, die Streams der untergeordneten Prozesse vom „Inherit“-Modus in den „Pipe“-Modus umzuschalten. Auf diese Weise sind die Prozessausgaben als Streams im untergeordneten Prozess verfügbar, anstatt direkt zum Haupt-stdout/stderr zu gehen. Wir müssen die Streams auch manuell leiten:

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

Durch das manuelle Weiterleiten der Streams wird sichergestellt, dass der Monkey-gepatchte Schreibvorgang vom Knoten aufgerufen wird.

Dies macht viele Integrationstests kaputt, aber sie sind hauptsächlich wegen fehlender Farbe kaputt. Tun

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

senkt diese Zahl erheblich, ist aber immer noch ziemlich hoch:

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

Ich glaube nicht, dass es einen Ausweg gibt - die Ausgabe wird drastisch geändert, da viel mehr Schreibvorgänge jetzt das Status-Update hinzufügen.

Bearbeiten: Es gibt auch das Problem, dass der Knoten den Ausgabestrom in bestimmten Situationen zu spät löscht, lange nachdem der untergeordnete Prozess eine Erfolgsmeldung an den übergeordneten Prozess gesendet hat.

Bitte beheben, das schadet wirklich der Produktivität mit Spaß

Ein Downgrade auf [email protected] bringt die Konsolenprotokollausgabe zurück. Musste jedoch --env node setzen, damit es funktioniert. Bitte beheben Sie dies.

Derzeit scheint es, dass die einzige Möglichkeit, die Konsolenprotokollierung zuverlässig zu machen, darin besteht, 3-4 Mal hintereinander dasselbe zu protokollieren. Jest blockiert nur eine bestimmte Anzahl von ihnen. Trotzdem sehr nervig.

Gibt es hierzu ein Update? Ich verwende jest 23.4.1 und den Knoten 9.11.1 und erhalte manchmal Konsolenprotokollausgaben und manchmal nicht.

Zwei Jahre ohne Konsolenprotokolle haben mich zu einem besseren Entwickler gemacht. Danke Team Jest!

Ich kann nicht glauben, dass das immer noch ein Problem ist. Warum ist das Thema geschlossen?

Ich meine, wer würde jemals seine fehlgeschlagenen Tests debuggen wollen, richtig?

Wie @jonogilmour erwähnt, wenn ich etwas protokolliere, wenn es nicht angezeigt wird, aber Dinge zweimal protokolliere, wird eines davon angezeigt.

FWIW, die Problemumgehung --verbose=false funktioniert für mich. In meinem package.json :

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

Einige andere Beobachtungen:

• Durch das Entfernen von --env=jsdom (keine Option für meine echte Anwendung) funktionierte es ohne --verbose=false.
• Das Ausführen des Tests direkt mit Jest (nicht über React-Skripte) hat auch funktioniert.
• Wenn eine Behauptung fehlschlägt und Sie viel mehr Ausgabe von Jest erhalten, werden auch viel mehr Ihrer Konsolenprotokolle überschrieben.

Hallo Jungs/Mädels,
Ich bin auch auf das berühmte Jest-Konsolenprotokollproblem gestoßen, als ich testing im --watch-Modus ausgeführt habe.
Die Lösung bestand darin, --watchAll anstelle von --watch zu verwenden. Die Zusammenfassung der Tests wurde hässlicher, aber die Protokolle wurden wie erwartet angezeigt.

macOS HighSierra
Knoten v8.11.3
Scherz: 23.6.0
ts-scherz: 23.10.4

Für mich ist das in beforeAll

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

und das in der Shell hat die Arbeit gemacht:

yarn test > test.log

Für mich löste der Wechsel zu mocha das Problem. Es ist sehr trivial zu wechseln, da das DSL sehr ähnlich ist. Sie können sogar weiterhin die Expect-Bibliothek von JEST verwenden: https://www.npmjs.com/package/expect

Es ist fast so einfach wie das Entfernen jest und das Installieren mocha .

Bearbeiten: Spam oder nicht, es ist die einfachste Lösung hier draußen.

Dieses Problem tut wirklich weh, ich wünschte, die Betreuer könnten es so schnell wie möglich beheben, denn Jest soll die Produktivität steigern, nicht umgekehrt, richtig?

Wie auch immer, das Folgende ist, was ich jetzt schreibe:

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

Du musst dir deinen Weg raus spammen.

Bestätigt, dass --verbose=false das Problem behebt.

--verbose=false funktioniert bei mir nicht mit Version 23.6.0

OMG das ist ein Schmerz :/ November 2018

Bitte öffnen Sie dieses Problem erneut

versuche silent: false in jest.config.js zu setzen ... in meinem Fall hat es mir geholfen

Keine der Lösungen funktioniert.
NodeJS: v8.12.0
Scherz: v23.4.1

Ich benutze Jest seit Monaten und es ist großartig, und obwohl dieser Fehler _super nervig_ ist, besteht die Problemumgehung, die ich immer verwendet habe, darin, eine Junk-Assertion zu erstellen, da dies jedes Mal auf der Konsole protokolliert wird.

Beispiel beim Versuch, einen Scheinanruf abzumelden:

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

Es ist nicht ideal, aber es erledigt die Arbeit und ermöglicht es mir, meine Tests fertig zu schreiben.

Ausführen von Jest mit einem --watch-Flag.
Jest-Version 23.5.0
Knotenversion 8.11.3

Dies ist ein anständiges Beispiel für „zu viel Magie“, die unter der Motorhaube vor sich geht, und die Folgen davon, wenn etwas schief geht. Ich bin nicht davon überzeugt, dass das Gruppieren der Ausgabe von console.log anderthalb Jahre fehlender console.log-Anweisungen wert ist. 😕

Stimmen Sie dem oben Gesagten zu – das ist nicht ganz ein Showstopper, aber es macht Jest auf eine Weise schmerzhaft, die völlig unnötig ist.

Meine "Problemumgehung" besteht darin, dass ein Großteil der Logik log4js verwendet, also wo ich Jest zu serverseitigem Code biege, bin ich gut. Leider habe ich eine große Menge an clientseitigem Code, in den ich normalerweise vier Kopien von jedem console.log kopiere und einfüge, da schließlich einer von ihnen auftaucht.

Die Verwendung expect zum Protokollieren von Informationen ist eine gute Problemumgehung, wenn Sie sich aus einem Test heraus anmelden (vor allem, da Sie in Ihrem Editor ein Snippet dafür mit einem Schlüsselwort wie logjest erstellen können), aber das greift zu kurz, wenn Sie tiefer graben und innerhalb der eigentlichen Funktionen, die Ihre Tests aufrufen, protokollieren müssen.

Wie wäre es mit CI=true yarn run test ?

Entschuldigung für das, was ich vorher gesagt habe, aber es funktioniert gut ohne den Titel der Testfälle, ich meine, ohne die Option "--verbose", ich denke, dass --verbose eine Art Formatierung durchführt und den stdout-Stream ersetzt.
Also, für mich war ich ungefähr 2 Monate und alles funktioniert gut.
Und wenn jemand diese Option verwenden möchte, dann fügen Sie sie nur so an Ihre npm-Befehle an: npm run test:integration -- --watchAll --verbose --coverage --etc

Können Personen mit dem Problem [email protected] testen? Es enthält #6871

@jamesta696 Hallo, ich denke, dass Sie diese Art von Fragen auf StackOverflow mit dem Tag "Jest" hier posten müssen, weil die Diskussionen hier für "Probleme" sind, trotzdem weiß ich, dass Ihnen jemand helfen könnte, aber das Problem hier könnte geschlossen werden, weil das Hauptthema nicht diskutiert wird.
Und im Moment kann ich Ihnen keine Antwort auf diese Frage geben, weil ich nichts für React und das Frontend entwickle, auch bin ich kein Mitglied von Jest, aber versuchen wir, die Regeln zu befolgen.

@SimenB Ich habe Jest (auf Ihre erwähnte Version) aktualisiert und versucht, ein paar console.log -Anweisungen in meinem Projekt zu platzieren, bei denen das Problem aufgetreten ist. Bisher scheint es behoben zu sein: Alle console.log s erscheinen. Ich werde es weiterhin verwenden und Sie informieren, wenn das Problem erneut auftritt.

FYI: Ich benutzte (und tue es immer noch) jest --watchAll

@tobyhinloopen Cool, einen Beweis für den Fortschritt zu sehen, der @SimenB erwähnt.

das ist großartig @tobyhinloopen!

Ich kann auch bestätigen, dass [email protected] gut funktioniert und Sie alle Konsolenprotokolle ohne --verbose=false sehen können.

Ich kann auch bestätigen, dass [email protected] gut funktioniert und Sie alle Konsolenprotokolle ohne --verbose=false sehen können.

+1. kann das auch bestätigen. froh zu sehen, dass dies funktioniert. Gute Arbeit, Jest Leute! 😄

Kann ich auch bestätigen! Es ist wie Weihnachten. 🎅

😃

Sie müssen nur nicht warten, bis Create-React-App-Updates erstellt werden

Ich verwende nur Version 24.0.0 , aber ich kann console.log oder console.error immer noch nicht sehen. Frage mich, was ich falsch machen könnte.

Stellen Sie sicher, dass sie nicht verspottet werden

Das ist wirklich seltsam. Es scheint ein Problem mit der asynchronen Behandlung zu geben. Ich bekomme die Fehler nicht angezeigt. Selbst wenn es in try/catch -Blöcke verpackt ist, kann ich den Fehler nicht sehen.

Der Parameter generator ist sicher korrekt, wenn ich den async-Funktionsaufruf entferne, dann wird er korrekt protokolliert. Es gibt auch die richtige Zeichenfolge zurück, wenn es sich außerhalb der for-Schleife befindet.

Jest-Version ist 24.0.0 , Knoten ist 10.5

@tiborsaas Ihr Test wird wahrscheinlich beendet sein, bevor console.log läuft.
Wenn Sie auf die Iteration über changedGenerators warten möchten, benötigen Sie so etwas wie

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

Danke für die Antwort, aber es ist nicht wirklich der Fall, ein Fehler verhindert, dass console.log angezeigt wird. Es gibt eine andere asynchrone Funktion, die gut mit console.log funktioniert, wenn ich sie im forEach Callback aufrufe.

Bearbeiten: Eigentlich durch zeilenweises Debuggen weiß ich, wo das Problem liegt

const archives = await fs.readdir(archiveDir);

Bei dieser Scherzausgabe geht es jedoch darum, Dinge zu protokollieren. Ich will das Gespräch nicht entgleisen.

Möglicherweise tritt immer noch ein Fehler auf. Ich wollte nur darauf hinweisen (ohne Ihren genauen Code zu kennen), dass es im Allgemeinen eine schlechte Idee ist, eine Reihe von Versprechen wie diese zu forken, ohne sie abzuwarten, da sie nach Abschluss Ihres Tests möglicherweise abgelehnt werden: )

Ich stimme zu, aber ich möchte die expect -Aufrufe in forEach ausführen, weil ich im Voraus nicht weiß, mit wie vielen Änderungen ich mich befassen muss.

Leider hat der Promise.all -Ansatz nichts behoben.

Hast du map statt forEach verwendet? Der Punkt ist, ein Array von Promises an Promise.all zurückzugeben

@SimenB Ja, ich weiß.

Wenn es einen Fehler gibt, kann ich ihn nicht sehen.

@tiborsaas Sie warten nicht darauf, dass Promise.all abgeschlossen ist: Verwenden Sie await Promise.all(...)

Habe das auch gemacht, gleiches Ergebnis. :(

Was ist, wenn Sie await new Promise((resolve) => setTimeout(resolve, 1000)) unter promise.all hinzufügen?

Können Sie mit einer Reproduktion ein neues Problem eröffnen? Ich glaube, das vom OP gemeldete Problem ist behoben, während Sie ein anderes sehen (egal, ob Sie mit Async richtig umgehen oder nicht, Sie sollten immer noch die Protokollanweisung sehen).

Ja, es ist in der Tat seltsam, so etwas wie

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

wird normalerweise noch irgendwie gedruckt

Er verwendet eine Callback-Funktion als zweites Argument von Promise.all([...], callback) . Er sollte Promise.all([...]).then(callback) verwenden. Vielleicht löst das sein Problem, ich denke, das 2. Argument von .all wird ignoriert und nie ausgeführt (also werden Ihre Protokolle nie ausgeführt). @tiborsaas

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

Ja, das ist falsch, aber Protokollanweisungen sollten trotzdem angezeigt werden

@SimenB Nein, das zweite Argument wird ignoriert.

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

Ja, war damit verwechselt, sorry. Danke @tobyhinloopen

const lol = await Promise.all(versions); hat wie erwartet funktioniert.

In diesem Fall gehen die Protokollanweisungen möglicherweise verloren, da die Funktion nie aufgerufen wird, aber Sie sollten weiterhin Protokollanweisungen im ursprünglichen forEach -Fall sehen, da der Knoten darauf wartet, dass die Zusagen abgeschlossen werden, bevor der Prozess beendet wird. Es ist also immer noch ein Fehler, obwohl es ein Benutzerfehler ist

PR: # 7731

Ich verwende https://www.npmjs.com/package/debug für die Protokollierung. Würde das mit Jest funktionieren?

Nein, nicht bis wir #6524 machen.

Ich würde empfehlen, debug in Ihren Tests zu verspotten und console.log zu verwenden, wenn Sie sie sehen möchten

Als Referenz können Konsolenmeldungen verloren gehen, wenn sie nach Abschluss der Tests gedruckt werden, siehe die Kommentare am Ende von #7731. Dies könnte der Grund für einige, aber wahrscheinlich nicht alle der hier gemeldeten fehlenden Konsolenmeldungen sein.

Das --verbose hat bei mir funktioniert. Vor der Verwendung von --verbose gingen einige, aber nicht alle Nachrichten verloren. Ich verwende den Knoten v10.15.3 und jest v21.2.1

Immer noch ein Problem für mich, Konsolenprotokolle werden in Jest nicht angezeigt

Trotz der neusten Ankündigung im Blog, dass das Problem endlich gelöst wurde, besteht das Problem immer noch, meine Konsolen-Logs werden manchmal nicht mehr angezeigt, ich verwende jest v24.8.0 .

Und meine funktioniert einwandfrei 🤷‍♂️. Bitte posten Sie eine Reproduktion, die wir untersuchen können. Wir sind keine Zauberer, wir können Ihren Code nicht sehen, der die Ausgabe nicht protokolliert.

Tatsächlich funktionieren nach einer Untersuchung Protokolle im Zusammenhang mit API-Tests (wie Supertest) nicht. erwartet :/

@thymikee Das passiert uneinheitlich, daher ist es wirklich schwer, es zu reproduzieren. Beispiel:
Folgen von Läufen durch Auswahl einer einzelnen Datei aus Tests ( Option p )

• console.log('pantz') (funktioniert)
• change console.log(myObject) (funktioniert nicht)
• Passen Sie es an (funktioniert nicht)
• Wechsel zu console.log('pantz') (funktioniert nicht)
• anpassen (funktioniert nicht)
• Jest neu starten (funktioniert nicht)
• ändere es so, dass es passt (funktioniert)

Jetzt habe ich versucht, dieselben Schritte zu wiederholen, und das Ergebnis ist inkonsistent.

Stellen Sie ein Beispiel-Repo bereit, in dem es nicht funktioniert, damit die JEST-Leute beim Debuggen helfen können. @kresli

Es gibt auch viele Möglichkeiten für Benutzerfehler, meistens fehlen await oder anderweitig asynchrone console.log 's.

Ich werde versuchen, eine Zeit zu finden, um das dann zu reproduzieren. Bis dahin habe ich festgestellt, dass meine Protokolle von Ergebnissen gefressen werden, wie Sie unten sehen können. Bevor FAIL erscheint, können Sie dort meine 2 Protokolle sehen. Und es ist auch erwähnenswert, dass nur 2 Protokolle entfernt werden. Wenn ich 10 Protokolle untereinander addiere, würden 8 angezeigt. Ich finde das ist ein guter Anfang :)

Wenn Sie in der Zwischenzeit einen Catch-All-Fix benötigen, der einfach funktioniert, können Sie etwas wie winston verwenden, um sich sowohl bei der Datei als auch bei der Konsole anzumelden. Auch wenn Ihre Konsolenmeldungen nicht angezeigt werden, werden sie in eine Datei geschrieben.

Mit winston können Sie konfigurieren, was Sie wo protokollieren möchten, und es unterstützt mehrere Transporte und Transporte, die Sie selbst implementieren können.

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)

Vielleicht können Sie sogar etwas Schmutziges tun, wie console.* global für Winstons Logger zu überschreiben.

@kresli welche version ist dein scherz? Das sieht nach v23-Verhalten aus

Das passiert mir immer wieder mit jest v^24.6.0 und node v10.14.2 . Irgendeine Idee warum?

@yaelz Dies ist ein hartnäckiges Problem, das häufig durch Benutzerfehler verursacht wird, aber auch eine Vorgeschichte von schwer reproduzierbaren Fehlern aufweist.

Ich denke, es würde den Mitwirkenden wirklich helfen, einen reproduzierbaren Fall bereitzustellen, indem sie ein Beispiel-Repo bereitstellen oder eine andere Möglichkeit zum Reproduzieren des Problems bereitstellen.

Danke für die schnelle Antwort!
Das wird schwierig, weil das aktuelle Repo in meiner Organisation privat ist ... Ich werde Sie wissen lassen, wenn ich dazu komme :)

Das passiert mir immer wieder mit jest v^24.6.0 und node v10.14.2 . Irgendeine Idee warum?

Ich habe kürzlich einige Abhängigkeiten in einem Projekt aktualisiert und habe kein Problem, ich bin vor einem Monat damit konfrontiert, aber es wurde in neueren Versionen gelöst, glaube ich ...

Können Sie bitte die Versionen teilen, die Sie jetzt verwenden, wenn es gelöst ist?

Am Montag, 5. August 2019 um 12:43 Uhr Norman Enmanuel [email protected]
schrieb:

Danke für die schnelle Antwort!
Das wird schwierig, weil das aktuelle Repo in meiner Organisation privat ist ... Ich lasse es
du weißt, ob ich dazu komme :)

Ich habe kürzlich einige Abhängigkeiten in einem Projekt aktualisiert und habe keine
Problem, ich bin vor einem Monat damit konfrontiert, aber ich wurde in neueren Versionen I gelöst
glauben...

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/facebook/jest/issues/3853?email_source=notifications&email_token=AB6F4PAE3CHUMEBP7IYXRPLQC7Y2DA5CNFSM4DPZ3JSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3RI3PY#issuecomment-903,163
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AB6F4PFXDSRHBW5CMTT2DKDQC7Y2DANCNFSM4DPZ3JSA
.

Können Sie bitte die Versionen teilen, die Sie jetzt verwenden, wenn es gelöst ist?

Sicher:

Scherz

^24.8.0

Knoten -v

v10.16.0

Und dies sind einige npm-Skripte, die ich verwende, um sowohl e2e, Integration, Unit als auch Acceptance auszuführen:

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

Und das ist die 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"
    }]
  ]
};

Ich hoffe es hilft.

Ich werde versuchen, eine Zeit zu finden, um das dann zu reproduzieren. Bis dahin habe ich festgestellt, dass meine Protokolle von Ergebnissen gefressen werden, wie Sie unten sehen können. Bevor FAIL erscheint, können Sie dort meine 2 Protokolle sehen. Und es ist auch erwähnenswert, dass nur 2 Protokolle entfernt werden. Wenn ich 10 Protokolle untereinander addiere, würden 8 angezeigt. Ich finde das ist ein guter Anfang :)

@kresli Was ist die Statusleiste und die Zeitausgabe, die Sie hier haben? Wenn ich meine Testsuite ausführe, sehe ich _RUN HARNESS test-harness/index.js_ und sonst nichts, bis alles läuft. Ich sehe dann meine console.log-Meldung ganz am Ende und die Zeile mit _RUN HARNESS..._ ändert sich zu _NUTZBAR MACHEN...._

Update: Bitte ignorieren, stellte sich als Problem in meinem Code heraus

Immer noch mit Knoten v12.16.1, jest 25.5.4, Typoskript 3.8.3 auf MacOS. Versuchte die Empfehlungen zur Verwendung von --runInBand, zum Deaktivieren / Aktivieren von Verbose und zur Verwendung von --silent=true, es hat nicht geholfen.