Jest: console.log wird beim Ausführen von Tests nicht ausgegeben

Habe dies gerade mit repl.it getestet: https://repl.it/EwfT/0

Die gute Nachricht ist, dass es wie erwartet funktioniert und die Ausgabe von console.log. Ich habe versucht, meine jest-Version auf 17.0.3 herunterzustufen, sah immer noch die gleichen Probleme. nvm zum Testen mit Knoten v6.9.2 installiert, und hurray console.log funktioniert mit jsdom, daher gehe ich davon aus, dass das Problem mit Knoten v7 zusammenhängt.

Danke, dass Sie dies gemeldet haben, aber das ist ein Duplikat von #2166 und passiert auch auf Node 6.

@thymikee Wie ist das ein Duplikat von #2166? In diesem Szenario gibt console.log nichts aus. Ich habe dieses Problem mit Node v4. Das Frustrierende ist, dass es heute früher gut funktioniert hat, und mit 0 Änderungen an meiner Umgebung bekomme ich keine console.log Ausgaben mehr an mein Terminal.

@thisissami es scheint, als ob Ihr Test oder Code dann nicht ausgeführt wird. Jests Testsuite übergibt Knoten 4 und Knoten 6, wodurch sichergestellt wird, dass das Drucken auf der Konsole einwandfrei funktioniert, und wir arbeiten an einem Fix für 7.3.

@cpojer - Meine Tests bestehen/ console.log Nachrichten werden nicht angezeigt . Ich habe dies entdeckt, als ich versuchte, die Eigenschaften eines bestimmten Objekts herauszufinden, indem ich es console.log ing und keine Ausgabe sah. Ich habe viele console.log Anweisungen hinzugefügt, und jetzt wird keine in meinem Terminal angezeigt. =/ Ich kehre derzeit zu Jest v17 zu sehen, ob sich daran etwas ändert.

Wenn es heute früher bei Ihnen funktioniert hat und nicht mehr, müssen Sie selbst ein Update gemacht oder etwas kaputt gemacht haben. Wir haben seit zwei Wochen kein Jest-Release veröffentlicht.

ok, das einzige, was sich in meinem Testcode geändert hat, ist, dass ich nach dem Code, der ausgeführt werden soll, einen mehrzeiligen Kommentar hinzugefügt habe (als Referenz für mich). Ich werde sehen, ob das Entfernen einen Unterschied macht.

@cpojer Ich weiß nicht, was ich sagen soll, ich sehe in meinem

import React from 'react';
import {shallow} from 'enzyme';
import FundPercentage from '../../src/reactClasses/fund_percentage';

console.log('cmon');
describe('Normal Percentage', () => {
  console.log('do this');
  const percentage1 = shallow(
    <FundPercentage percentage={0.5}/>
  );
  const percentage2 = shallow(
    <FundPercentage percentage={0.26}/>
  );
  it('should work', () => {
    console.log(percentage1.childAt(0));
    expect(0).toBe(1);
  });
});

Der Test schlägt wie erwartet fehl, also weiß ich, dass er funktioniert. Meine Konfiguration in package.json ist wirklich einfach, nur:

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

Jest lief ganz normal, keine zusätzlichen Flaggen angebracht. Gleiches Problem mit Jest v17 & 18.

Ich habe den ganzen Nachmittag keine anderen Dateien als diese geändert. Ich habe gerade verstanden, wie enzyme funktioniert, indem ich verschiedene Dinge an stdout , und nachdem ich angefangen hatte, etwas expects hinzuzufügen, hörte das console.logs auf funktionieren, als ich sie wieder brauchte, und jetzt funktionieren sie überhaupt nicht - egal, was ich im Test habe. Ich habe auch in meiner Umgebung nichts geändert (außer dem Downgrade gerade auf v17), was sicherlich verwirrend ist.

Es scheint, als ob Sie auf Knoten 7.3 aktualisiert haben. Dafür haben wir einige Korrekturen parat. Bitte beachten Sie, dass dieser Issue Tracker kein Hilfeforum ist; benutze Stackoverflow für Fragen :)

Ich verwende den Knoten v4.4.7, und was mich betrifft, ist es ein Problem, dass bei der Verwendung von console.log nichts auf stdout angezeigt wird. Ich versuche nicht, Hilfe beim Programmieren zu bekommen, ich melde einen Fehler, der mir scheint. Die einzige andere Sache, die sich geändert hat, ist, dass ich zuvor mehrere Testdateien ausgeführt hatte, und jetzt nur noch eine. Lassen Sie mich sehen, ob das erneute Aktivieren der anderen Tests dazu führt, dass console.log Ausgaben wieder erscheinen.

@cpojer Ich bin mir ziemlich sicher, dass ihr hier einen Fehler habt.

Die Ausführung von 3 Tests (wie in 3 verschiedenen Dateien mit .test.js , wobei 2 dieser Dateien Beispiele aus Ihren Tutorials sind) funktioniert ohne Probleme. Mein Test (oben kopiert) rendert alle console.logs.

Nach nur einem Testlauf (auch bekannt als .test.js in .teast.js für 2 der Dateien umbenennen) führt dies dazu, dass keine console.log-Ausgaben gerendert werden.

Ich werde weiterhin einen zweiten willkürlichen Test ausführen, damit ich die Ausgabe sehe, die ich brauche, damit ich für meine persönlichen Bedürfnisse gut bin - aber dies sollte imo angegangen werden, vorausgesetzt, es ist an anderer Stelle reproduzierbar.

Die Testsuite von Jest testet dieses Verhalten auf Knoten 4, Knoten 6 und Knoten 7.3. Es funktioniert für 4 und 6, war aber in 7.3 defekt. Ich behebe das für Node 7.3 und werde in Kürze eine neue Version von Jest veröffentlichen: https://github.com/facebook/jest/pull/2464

Wenn Jests eigene Testsuite mit Knoten 4 für Sie fehlschlägt, dann stimmt wahrscheinlich etwas mit Ihrem Setup nicht.

Klonen Sie das Repository und probieren Sie es jetzt aus.

Bis auf diese 3 Tests hat alles bestanden. Ich bin mir nicht sicher, welche Auswirkungen das haben könnte. Sie haben alle Informationen zu den Fehlern im Zusammenhang mit console.log, die ich habe, sowie das Bild unten. Wenn das kein Scherzfehler ist, dann soll es so sein. Es erscheint mir jedoch seltsam, dass das Befolgen der Anleitungen zu einem Szenario führen würde, in dem ich meine Protokolle nicht sehen kann, wenn nur eine Testdatei ausgeführt wird.

Diese zeigen nur an, dass Sie kein Quecksilber (hg) installiert haben, unabhängig von Ihrem Problem. Es scheint, als ob die Testsuite für Sie bestanden hat, und wie gesagt; Wir testen das Protokollierungsverhalten explizit in der Testsuite, also muss etwas mit Ihrem Code oder Setup schief gehen.

Ok cool - danke für dein Feedback. Haben Sie eine Ahnung, was dazu führen könnte, dass es funktioniert, wenn mehrere Dateien vorhanden sind, aber nicht, wenn es nur eine gibt? Wenn Ihnen kein offensichtliches "Oh, dies verursacht manchmal ein solches Problem" in den Sinn kommt - keine Sorge, ich sorge nur dafür, dass immer mindestens 2 Dateien ausgeführt werden. :)

Ich habe das gleiche Problem, console.log wird jetzt nicht für mich ausgegeben (und das war vor etwa einer Stunde). Ich verwende den Knoten 6.9.1 und aktiviere auch das Flag --forceExit. Wenn dieses Flag nicht aktiviert ist, wird die Ausgabe von console.log angezeigt.

Ich habe jedoch ein anderes Testskript, das das Flag --forceExit verwendet und console.log erscheint, daher kann ich nicht sagen, dass das Flag --forceExit dieses Verhalten verursacht.

Wie bei @thisissami tritt das Protokollierungsproblem nur auf, wenn ich versuche, eine einzelne Datei zu testen.

Ich hatte das gleiche Problem, stellte jedoch fest, dass es daran lag, dass jest über jest-cli (jest.runCLI) in gulpfile.js ausgeführt wurde und die Ausgabe von console.log verschluckt wurde. Wenn ich jest direkt ausführe, sehe ich die Konsolenausgabe.

Ich habe jetzt ein komisches Verhalten, das ich noch nicht auf einen einfachen Testfall isolieren kann, sonst würde ich ein neues Problem einreichen.

1) Jest macht einen Test
2) Jest gibt die console.log-Anweisungen aus (hier nicht blinzeln)
3) Jest scrollt eine beliebige Anzahl von Zeilen zurück nach oben, was manchmal alle Zeilen der console.log abdeckt, manchmal einige und manchmal alle.
4) Jest führt den nächsten Test aus (console.log-Zeilen vom vorherigen Test verschwinden).

Witz v18.1.0

Da ich dies nicht in einem einfachen Test isolieren kann, vermute ich, dass es etwas mit der Ausführung eines komplexeren asynchronen Tests zu tun hat.

Ich habe das gleiche Problem, ich frage mich, ob die Ausgabe andere Ausgaben überschreibt. Gelegentlich sehe ich so etwas:

Es ist, als hätte ein Prozess einen Fehler ausgegeben (fehlgeschlagene Prop-Typen), aber er wird einfach von den Testausgabeprotokollen überschrieben.

Mehr:

Und manchmal, wenn ich Ctrl + c während die Tests ausgeführt werden, sehe ich Konsolenprotokolle, die ich nicht sehen würde, wenn ich die Tests beenden würde.

Versionen
Witz: 17.0.1
Knoten: 6.6.0
NPM: 3.10.3
macOS: 10.12.2
Terminal: 2.7.1 (und auch in iTerm2 3.0.13)
Skript (in package.json ): jest /src/main/js --watch oder jest /src/main/js --coverage oder jest --watch --onlyChanged alle das gleiche Verhalten.

@davidgilbertson passiert es auf v18.1?

Ich habe 18.1.0 ausprobiert und es scheint noch fehlerhafter zu sein. Und ich sehe immer noch Dinge wie diese:

Ich kann kein bestimmtes Muster auswählen, aber einige Dinge sind passiert (ich habe ein console.warn('----------------') in einer meiner Komponenten.)

• Wenn ich beim Ausführen der Tests etwas von unten nach oben gescrollt werde, sehe ich das Protokoll. Wenn ich während der Tests im Terminalfenster nach unten scrolle (so dass das automatische Scrollen beginnt), scrolle ich nach Abschluss des Tests wieder nach oben und die Zeile console.warn ist weg (vermutlich überschrieben).
• Wenn ich die Tests ausführe und sofort ctrl + c , sehe ich einige Konsolenprotokolle. Aber wenn ich dasselbe tue und nicht unterbreche, sind diese Konsolenprotokolle nicht sichtbar.
• Wenn ich jest /src/main/js --watch einmal ausführe und dann a drücke, um es erneut auszuführen, greift es eine ganze Menge Legacy-Tests in einem Verzeichnis src/main/assets/legacy - das nicht mit dem Glob übereinstimmt.
• Wie oben, wenn ich nur jest --watch ausführe (alle meine Tests enden in .test.js oder .test.jsx ). Das Drücken von 'a' im Watch-Modus scheint also überall zu suchen, einschließlich eines alten Jasmintests namens src/test/js/spec/categoryselector/spec.js . Das Schlagen von Enter scheint das zu tun, was ich erwarte.

Könnte es sein, dass alle Fehler, die durch fehlende Requisiten ausgelöst werden, dieses Problem verursachen? Ich muss ctrl+c die Ausgabe weitergeben, um zu versuchen, diese Fehler abzufangen, bevor sie überschrieben werden.

Funktioniert bei mir auch nicht (jest 19.0.1, Knoten 5.12). Interessanterweise funktioniert es in einem anderen Projekt mit demselben Setup. Ich bin mir nicht sicher, wie man Jest-Tests debuggen soll, daher wäre es meiner Meinung nach sehr wichtig, einige Konsolennachrichten sehen zu können.

Haben Sie versucht, das Scherz-Flag --runInBand zu verwenden, um zu sehen, ob dies durch seriell ausgeführte Tests gelöst wird? Jemand hat mir das gesagt, hatte aber noch keine Gelegenheit, es zu testen.

Das Flag bail verhindert, dass die Konsolenprotokolle gedruckt werden.

Ich werde es versuchen. Das etwas nervige daran ist, dass im selben Projekt einige Konsolen-Log-Statements auf der Konsole ausgegeben werden, andere nicht. Leider erhalten diejenigen, die ich versucht habe, hinzuzufügen, wo ein Testfall fehlschlägt, keine Ausgabe (ich habe versucht, überall im Testfall, in der getesteten Einheit usw. ohne Erfolg hinzuzufügen). Ich glaube also nicht, dass dies an einer Flagge liegen kann, da das Verhalten nicht prägnant ist. Es ist ein reaktionsnatives Projekt, das übrigens dem Standard-Layout folgt.

Nichts davon scheint zu helfen. Das Flag --bail verhindert nur, dass andere Tests ausgeführt werden (der beleidigende ist sowieso der letzte in meinem Fall), und --runInBands scheint keinen beobachtbaren Unterschied zu haben. Jest führt die aktualisierten Dateien übrigens aus. Wenn ich also eine console.log-Anweisung einfüge, zeigt der Fehler-Stack-Trace den Fehler an, der von der aktualisierten Zeilennummer herrührt. Es ist nur das Konsolenprotokoll nicht passiert. Da es schwierig/unmöglich ist, diese Tests in einem Browser zu debuggen (bitte korrigieren Sie mich, wenn dies nicht der Fall ist), ist console.log absolut wichtig, um einige Probleme in den Tests zu beheben.

Es scheint, dass dieser Testfall tatsächlich nicht ausgeführt wurde. Es gab einen TypeError (Zugriff auf eine Eigenschaft auf einem undefined). Was mich in die Irre führt, ist, dass ich tatsächlich den Stack-Trace auf der Konsole gesehen habe, was irgendwie darauf hindeutet, dass er ausgeführt wird. Also, den Trace zu sehen, aber die Log-Meldung nicht zu sehen, summierte sich nicht ganz :) Weiß jemand, warum dies auf diese Weise geschieht. Wenn ein Test mit einem Laufzeitfehler fehlschlägt, werden die Logs nicht so ausgegeben, wie es scheint? (Nur um es klarzustellen, ich meine Protokolle, die bis zum Fehler aufgetreten sind, ich meine natürlich nicht Protokolle nach dem Fehler :))

In meiner Umgebung hatte ich verbose: true in den Scherzoptionen in package.json . Das Ändern auf false (oder Entfernen) hat das Problem für mich behoben. Alle meine Konsolenprotokolle werden jetzt angezeigt.

Das ist am 18.1.

Für alle anderen, die auf dieses Problem stoßen, überprüfen Sie alle kürzlich hinzugefügten Abhängigkeiten. Ich fing an, auf Probleme zu stoßen, nachdem ich mock-browser hinzugefügt hatte, um Browserobjekte zu verspotten. Anscheinend ersetzt es global durch ein eigenes Objekt.

package.json (jest config)

"jest": {
    "testEnvironment": "node",
    "moduleFileExtensions": [
        "js",
        "json"
    ],
    "moduleDirectories": [
        "node_modules",
        "src"
    ],
    "transform": {
        "^.+\\.js$": "babel-jest"
    },
    "roots": [
        "<rootDir>/__test__"
    ],
    "setupFiles": [
        "<rootDir>/__test__/test-setup.js"
    ],
    "moduleNameMapper": {
        "client": "<rootDir>/src/client",
        "common": "<rootDir>/src/common",
        "server": "<rootDir>/src/server",
        "!CONFIG": "<rootDir>/config/env/test.js",
        "\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$": "<rootDir>/__mocks__/file.js",
        "\\.(css|less)$": "identity-obj-proxy"
    }
}

test-setup.js

const mockBrowser = require('mock-browser').mocks.MockBrowser;

const MockBrowser = new mockBrowser();
global.APP_CONFIG = require('!CONFIG').default;

global.__DEVELOPMENT__ = false;
global.__TESTING__ = true;
global.__PRODUCTION__ = false;
global.document = MockBrowser.createDocument();
global.window = MockBrowser.createWindow();
global.localStorage = MockBrowser.getLocalStorage();

test-setup.js
Die mock-browser Bits auskommentieren...

// const mockBrowser = require('mock-browser').mocks.MockBrowser;

// const MockBrowser = new mockBrowser();
global.APP_CONFIG = require('!CONFIG').default;

global.__DEVELOPMENT__ = false;
global.__TESTING__ = true;
global.__PRODUCTION__ = false;
// global.document = MockBrowser.createDocument();
// global.window = MockBrowser.createWindow();
// global.localStorage = MockBrowser.getLocalStorage();

console.log funktioniert einwandfrei.

Warum ist dieses Thema geschlossen? Ganz klar kein Duplikat von #2166

Ich werde meine 0,02 $ hinzufügen, weil ich gerade darauf gestoßen bin.

Problem:

• Ich verwende jest --watch --verbose (v19.0.2)
• Einige (aber nicht alle!) console.log Anweisungen erscheinen weder beim Testlauf noch in der Zusammenfassung
• In meinem Fall kann ich es auf einen _.reduce Aufruf isolieren: alle console.log Anweisungen innerhalb dieses Blocks werden nicht angezeigt , console.log Anweisungen außerhalb des Reduce-Blocks werden angezeigt . Ich habe auf andere Weise (Abdeckung, Testergebnisse) überprüft, dass der Reduzierkörper tatsächlich aufgerufen wird. Das ist seltsam, da ich in diesem Teil des Codes nichts asynchrones/versprechendes mache, kann ich nicht ergründen, warum der Aufruf von Reduzieren irgendetwas beeinflussen würde.
• Wenn ich mit --runInBand jest aufrufe, sehe ich alle console.log Anweisungen.
• Im Gegensatz zu den meisten vorherigen Berichten arbeite ich mit "testEnvironment": "node" , nicht mit jsdom

Die folgenden Kommentare scheinen mit meinem Problem zu tun zu haben:

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

Es ist ziemlich schnell, aber es scheint , wie die console.logs tatsächlich auf dem Bildschirm gezeichnet werden, und dann überschrieben.

Habe gerade mit einem Video bestätigt, dass console.log tatsächlich ~0,2 Sekunden lang auf den Bildschirm gezogen wird, bevor es übergezogen wird.

Das Ausführen von --watch ohne --verbose scheint dies zu beheben.

Ich habe 10 Minuten damit verbracht, einen isolierten Repro-Fall zu bekommen, aber ich schaffe es anscheinend nicht. Es manifestiert sich wahrscheinlich nur bei großen (naja, >1) Testsuiten.

Sie können das Verhalten hier sehen:

• Vor Konsole.log
  

• console.log - wird für den Bruchteil einer Sekunde angezeigt (<0,2 s)
  

• Nachdem console.log übermalt wurde
  

Dieses Problem ist wirklich scheiße, es wird viel Zeit mit diesem Problem verschwendet und nichts scheint zu funktionieren. Ich habe mich für einen Scherz entschieden, weil ich dachte, dass Facebook-Ingenieure eine anständige Testsuite hätten, und jetzt ist dies...

Deshalb mag ich Jest nicht. Egal was Sie tun, sie werden Ihre Konsole löschen und sich weigern, Konsolenanweisungen anzuzeigen, und dann werden sie irgendwie zufällig angezeigt, bis Sie einen Fehler haben, den Sie beheben müssen. In diesem Fall werden sie ihr Bestes tun, um alle zu verbergen log-Anweisung, sodass Sie sie nicht beheben können.

Warum hörst du nicht auf, die Konsolenausgabe vor den Entwicklern zu verbergen? Wenn ich Stützräder möchte, verwende ich Angular 1!

Das ist ziemlich aggressiv @halis. Wir tun dies, weil Jest Tests parallelisiert und viele Tests gleichzeitig im Terminal protokolliert werden können, was bedeutet, dass die Ausgabe von Jest nutzlos wird. Das haben wir tatsächlich früher gemacht. Wenn Sie --verbose , puffern wir nichts und schreiben direkt in die Konsole.

Wenn das bei Ihnen nicht funktioniert, können Sie uns vielleicht helfen, indem Sie eine PR an Jest senden und dieses Verhalten verbessern.

Es tut mir leid, ich hatte am Freitag einen wirklich schlechten Tag und war frustriert. Kein Grund, es an dir auszulassen, du versuchst nur zu helfen.

Ich habe am Freitag das Flag --verbose gefunden, das mir genug Ausgabe gab, um meine Probleme zu beheben.

Nochmals, Entschuldigung, dass ich so ein Arschloch bin.

Das ist großartig. Lassen Sie sich Ihre Freitage nicht von JavaScript-Tools verderben 😀

Gibt es Neuigkeiten zu diesem Thema? Wie zeige ich console.log an?

sehr interessantes Verhalten, nachdem ich mir ein paar Mal (eher mehrere Male) den Kopf geschlagen hatte, stellte sich heraus, dass --verbose tatsächlich der Schuldige ist, der Konsole.log nicht ausgedruckt hat.
Meine beste Lösung war, ein weiteres Skript in package.json zu erstellen, das kein ausführliches Flag enthält, wenn ich möchte, dass einige Nachrichten in meiner Konsole ausgedruckt werden. Wäre echt dankbar, wenn ihr das bald behebt

Dieses Problem ist in der Tat ziemlich ärgerlich, da es das Debuggen von Tests mit console.log schwierig/unmöglich macht (ich weiß.. Old School, aber immer noch praktisch).
Wenn ich die --runInBand Optionen verwende, wurden meine Protokollanweisungen angezeigt.

BEARBEITEN: Ich bin mir ziemlich sicher, dass es mit der Art und Weise zusammenhängt, wie das Ergebnis auf dem Bildschirm angezeigt wird ... eine Option wäre, einen "Dummy" -Reporter zu haben, der einfach kein ausgefallenes Rendering versucht. Eine andere Möglichkeit wäre, den Entwickler einen Reporter auswählen zu lassen, wie es Mocha tut.

Es ist schlimmer, als keine Protokolle anzuzeigen:

Wenn bei einem asynchronen Test ein Fehler aufgetreten ist, werden nicht nur keine Protokollmeldungen angezeigt, sondern auch die expect Fehler werden ausgeblendet und Ausnahmen werden verschluckt.

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

Nirgendwo wird mein expect Test angezeigt.

````
Zeitüberschreitung – Async-Callback wurde nicht innerhalb der von jasmine.DEFAULT_TIMEOUT_INTERVAL angegebenen Zeitüberschreitung aufgerufen.

  at Timeout.callback [as _onTimeout] (../../../../../../../../usr/local/lib/node_modules/jest/node_modules/jsdom/lib/jsdom/browser/Window.js:523:19)
  at ontimeout (timers.js:386:14)
  at tryOnTimeout (timers.js:250:5)
  at Timer.listOnTimeout (timers.js:214:5)

````

Weder runInBand noch verbose:false helfen.

Ich habe eine trivial einfache ( babel-jest ) Konfiguration.

@richburdon für asynchrone Tests mit done Callback müssen Sie einen fehlgeschlagenen Fall mit done.fail() abdecken

@thymikee danke für die schnelle Antwort. ich weiß aber nicht was du meinst. Können Sie meinen Test ändern und / oder mich auf Dokumente verweisen. Vielen Dank.

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

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

Ich verstehe, dass dies nicht ideal ist, aber so funktioniert es derzeit. Es ist erwähnenswert, dass es kein Problem ist, wenn die getestete Funktion ein Promise zurückgibt . Von diesem Verhalten sind einige Probleme betroffen, z. B. https://github.com/facebook/jest/issues/2136 oder https://github.com/facebook/jest/issues/2059. Wenn Sie eine Idee zur Verbesserung haben, prüfen wir gerne eine PR und setzen sie um.

Dies ist jedoch kein relevantes Thema, um es zu diskutieren. Sie können Ihre Ideen an anderer Stelle veröffentlichen.

@thymikee , mein Beispiel war kein gutes, da setTimeout Probleme mit Versprechen hat, die nichts mit Scherz zu tun haben ...

Es ist erwähnenswert, dass es kein Problem ist, wenn eine getestete Funktion ein Promise zurückgibt.

das sehe ich nicht:

````
test('async', (erledigt) => {
Funktion foo() {
Rückgabe Promise.resolve(1);
}

foo().then(Wert => {
erwarten(Wert).toEqual(2); // Nie gemeldet; einfach mal aus.
fertig();
});
});
````

Es ist nicht offensichtlich, dass Testcode Ausnahmen für expect Aufrufe abfangen sollte (dh Teil des Testframeworks selbst). Das sieht ziemlich verworren aus?

Um das klarzustellen, sollte ich ALLE Tests, die getestete Funktionen beinhalten, die Promises zurückgeben, mit einem catch-Block umschließen – um expect Aufrufe abzufangen, die andernfalls: a) Zeitüberschreitung; b) den Fehler nicht melden.

Es sei denn, ich mache einen anderen Fehler:

ein). Vielleicht dokumentieren Sie dies (https://facebook.github.io/jest/docs/asynchronous.html#content)?

B). Warum protokollieren Sie den Fehler nicht? und/oder haben Sie eine Option zum Ausstieg?

Wechsel zu https://github.com/facebook/jest/issues/3576

Ich habe das gleiche Problem mit console.log.
Es hat in v19 gut funktioniert und ich konnte die Ausgabe in der Konsole sehen.
Nach dem Upgrade auf v20.0.3 ist die Ausgabe weg.
Ich habe versucht, --runInBand oder --verbose hinzuzufügen, aber es hat nicht geholfen.

Aktualisieren Sie bitte auf die neueste Version von nodejs. Es ist ein bekanntes Problem in Knoten ~7.3.

@thymikee Werden sie dieses Problem beheben? Ich habe alles unter der Sonne probiert. Immer noch keine Konsolenlogs. Ich verwende Typoskript und den von Jest bereitgestellten Präprozessor. Ich habe ts-jest verwendet und ihr Präprozessor funktionierte. Kann es etwas mit dem Präprozessor zu tun haben?

@cpojer @lsentkiewicz Sollten wir eine neue Ausgabe eröffnen, da es sich um eine neue Ausgabe mit einer neuen Version handelt?

Wie @cpojer erwähnt hat, behebt die Verwendung der neuesten Version von node das Problem.

@marcusjwhelan
Funktioniert bei mir auf v7.10.0

Ich sehe immer noch, dass die Konsolenausgabe verschluckt wird, wenn jest --bail .

@cpojer Funktioniert nicht auf v8.0.0

Funktioniert nicht auf Knoten 8.0.0

Ich habe das Gefühl, dass dies ein schlimmer Fehler ist, wenn Sie auf einer bestimmten Version sein müssen, damit es funktioniert. Was ist, wenn Ihr System mit 6.0 ausgeführt wird und es in 7.0 aufgrund von Nodejs-Änderungen nicht funktioniert. Sollte es nicht zumindest auf modernen Versionen von Node funktionieren? Mindestens 5 Jahre Support? @cpojer @taion

Dies ist nur ein Fehler in Knoten 7.3. Sie haben eine fehlerhafte Änderung zusammengeführt und für 7.4 oder 7.5 zurückgesetzt.

Die Leute sagen mir, dass es auf Knoten 8 nicht funktioniert, aber wir haben einen Test für dieses Verhalten und es besteht. Wenn Leute mit Jest 20 und Node 8 ein richtiges Repro erstellen möchten, dann erstellen Sie bitte ein Problem dafür.

@cpojer Ich sehe bei diesem Setup (macOS) keine console.log-Ausgabe:

$ node --version
v7.4.0

Dateien

package.json :

{
  "dependencies": {
    "@types/jest": "19.2.4",
    "jest": "20.0.4",
    "ts-jest": "20.0.6",
    "typescript": "2.3.4"
  }
}

__tests__/jestconfig.json :

{
  "rootDir": "../",
  "globals": {
    "__TS_CONFIG__": {}

  },
  "moduleFileExtensions": [
    "ts",
    "tsx",
    "js",
    "jsx",
    "json"
  ],
  "transform": {
    "\\.(ts|tsx)$": "<rootDir>/node_modules/ts-jest/preprocessor.js"
  },
  "testRegex": "__tests__/.*test_.*\\.(ts|tsx|js)$"

__tests__/test_foo.ts :

import {} from 'jest';

console.log('CONSOLE before test');
test('fail', () => {
  console.log('CONSOLE inside test');
  expect(true).toEqual(false);
  console.log('CONSOLE end of test');
})

__tests__/test_bar.js :

console.log('BAR CONSOLE before test');
test('fail', () => {
  console.log('BAR CONSOLE inside test');
  expect(true).toEqual(false);
  console.log('BAR CONSOLE end of test');
})

Ausgabe

$ jest -c __tests__/jestconfig.json 
 FAIL  __tests__/test_foo.ts
  ● fail

    expect(received).toEqual(expected)

    Expected value to equal:
      false
    Received:
      true

      at Object.<anonymous> (__tests__/test_foo.ts:6:16)
      at Promise.resolve.then.el (node_modules/p-map/index.js:42:16)

 FAIL  __tests__/test_bar.js
  ● fail

    expect(received).toEqual(expected)

    Expected value to equal:
      false
    Received:
      true

      at Object.<anonymous>.test (__tests__/test_bar.js:4:16)
      at Promise.resolve.then.el (node_modules/p-map/index.js:42:16)

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

Einzel-JS-Test:

$ jest -c __tests__/jestconfig.json __tests__/test_bar.js 
 FAIL  __tests__/test_bar.js
  ● fail

    expect(received).toEqual(expected)

    Expected value to equal:
      false
    Received:
      true

      at Object.<anonymous>.test (__tests__/test_bar.js:4:16)
      at Promise.resolve.then.el (node_modules/p-map/index.js:42:16)

  ✕ fail (7ms)

Test Suites: 1 failed, 1 total
Tests:       1 failed, 1 total
Snapshots:   0 total
Time:        0.596s, estimated 1s
Ran all test suites matching "__tests__/test_bar.js".

Einzel-TS-Test:

$ jest -c __tests__/jestconfig.json __tests__/test_foo.ts 
 FAIL  __tests__/test_foo.ts
  ● fail

    expect(received).toEqual(expected)

    Expected value to equal:
      false
    Received:
      true

      at Object.<anonymous> (__tests__/test_foo.ts:6:16)
      at Promise.resolve.then.el (node_modules/p-map/index.js:42:16)

  ✕ fail (116ms)

Test Suites: 1 failed, 1 total
Tests:       1 failed, 1 total
Snapshots:   0 total
Time:        1.27s
Ran all test suites matching "__tests__/test_foo.ts".

Habe das gleiche Problem mit Knoten v8.1.2. Ich habe auch Knoten v7.10.0 ausprobiert und das hat auch nicht funktioniert

Bei der Arbeit an einem React-Projekt habe ich Jest ausprobiert, weil es bei Jasmine eine totale Aufgabe ist, HTTP-Aufrufe mit whatwg-fetch , Node.js-Ausführung und Babel-Transpilation zu testen. Aber als ich sah, dass man mit Jest im Moment nicht auf die Konsole drucken kann, war das ein No-Go, dieses Framework zu verwenden. Habe das Problem mit Node.js 7.10 und Jest 20.0.4.

Schließlich konnte ich die gesamte Testumgebung mit Jasmine- und Node.js-Ausführung einrichten, indem ich xmlhttprequest für den globalen Geltungsbereich deklarierte und nock als gefälschten Server verwendete.

Fehler können sehr schwer zu fangen und zu beheben sein. Aber dieses hier ist ein P0, das vor 6 Monaten gemeldet wurde und niemanden daran hindern wird, Jest ernsthaft als Testrahmen für jedes React-Projekt in Betracht zu ziehen.

Ich hatte das gleiche Problem wie in den Screenshots von @davidgilbertson (Testergebnisse überschreiben console.log) auf Jest 19.0.2 und Node 7.10.0, als jest --verbose . Was mir geholfen hat: bei Verwendung von jest --verbose --runInBand funktionierte es korrekt (erst Testergebnis, dann alle console.log).

@cpojer @thymikee würden Sie dieses Problem bitte erneut öffnen, damit es Aufmerksamkeit erregt?

@iffy , können Sie bitte ein separates Problem mit Ihrem Repro erstellen? Ich werde versuchen, es zu triage und sehen, was nicht stimmt.
Übrigens, nichts unterhalb von Expect wird jemals gecallt, weil Throws erwartet werden.

@thymikee fertig (obwohl ich bereits auf Mokka

Ich hatte dieses Problem auch, und selbst nachdem ich diesen ganzen Thread gelesen und alles versucht habe, kann ich das Problem nicht beheben. Mein Test ist sehr einfach, weil ich gerade jest in meiner App implementiert habe und trotzdem console.log nicht angezeigt wird.

Dann habe ich versucht, winston zu verwenden, um mich in einer Ausgabedatei anzumelden, und es hat funktioniert. Dann habe ich versucht, mich mit winston an der Konsole anzumelden, und stell dir vor, es hat funktioniert!

Also schlage ich euch vor, dasselbe zu tun. Überprüfen Sie meine logger.js Datei:

'use strict';

const winston = require('winston');

const customColors = {
  trace: 'white',
  debug: 'blue',
  info: 'green',
  warn: 'yellow',
  crit: 'red',
  error: 'red'
};

let config = {
  colors: customColors,

  levels: {
    trace: 0,
    debug: 1,
    info: 2,
    warn: 3,
    crit: 4,
    error: 5
  },
  transports: [
  ]
};

config.transports.push(
  new(winston.transports.Console)({
    name: 'consoleLogger',
    level: 'error',
    colorize: true,
    timestamp: true
  })
);

const logger = new (winston.Logger)(config);
winston.addColors(customColors);

module.exports = logger;

Die in den Testdateien verwenden einfach:

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

Winston funktioniert, weil es process.stdout.write das diesen Fehler in Jest umgeht. Am Ende habe ich mein eigenes console.log erstellt, indem ich das util Modul von Node verwendet habe.

@eranimo @Daymannovaes schau dir Fehler #3853 an

Dieser Kommentar sagt, dass es mit 8.1.2 funktioniert, aber ich habe es versucht und es funktioniert nicht. Ich bin bereits auf Mokka umgestiegen, weil das ein ziemlich schlimmer Fehler war.

Wird dieser Fehler in der nächsten Version behoben? Und wo finde ich, wann das ist?

Ich kann nicht auf die neueste Version von Node aktualisieren (keine Option), daher ist dies keine Lösung. Ich könnte mein eigenes Logger-Utility machen, mit dem ich herumspielen kann. Ich erwäge, auf Mokka umzuwandeln, aber es hängt davon ab, wie mein Logger-Utility-Experiment verläuft.

Bitte beheben Sie so schnell wie möglich, Konsolenprotokolle sind äußerst hilfreich, um meine Tests zu schreiben.

Ich habe vorübergehend auf 19.0.2 herabgestuft und das funktioniert.

Ich hatte das gleiche Problem und habe es gerade mit der neuesten Version von Node getestet. Es funktioniert jetzt. :100:

Bei mir funktioniert es auch nach dem Wechsel von Node.js v7.10 auf v8.1.

für mich behoben beim Aktualisieren des Knotens von 7.4.0 -> 8.2.1

Erhalten Sie dies auf Knoten v8.4.0 und Jest 21.0.0-beta.1.

Wenn nur ein einzelner Testfall mit test.only , wird die Ausgabe von console.log nicht angezeigt.

Aber wenn ich --testPathPattern file entferne und alle Tests ausführe, wird die Ausgabe angezeigt.

Auch wenn ich await Promise.delay(100) als letzten Schritt im Test hinzufüge, wird die Ausgabe angezeigt.

Entschuldigung für diesen Kommentar, aber es ist eine Möglichkeit, Jest in Echtzeit auf console.log zu bringen, anstatt nachdem ein Test bestanden oder fehlgeschlagen ist. mein Test verwendet eine while-Schleife Ich habe versucht, die protokollierten Werte abzurufen, während die Schleife ausgeführt wird?

@nharrisanalyst verwendet das --verbose Flag

vielen Dank für die Antwort, aber ich verwende dieses Flag und es wird nur console.log() verwendet, nachdem ein Test entweder bestanden oder fehlgeschlagen ist. Wenn also meine while-Schleife hängen bleibt, kann ich sie beim Testen nicht mit console.log debuggen, da der Test weder besteht noch fehlschlägt, er bleibt einfach in einer Schleife hängen.

Jest scheint jede Konsole zu fressen, die ich in einem setupFiles , setupTestFrameworkScriptFile oder beforeAll mache, was es unmöglich macht, Test-Setup-Skripte zu schreiben, die nach Benutzereingaben und Validierungsbefehlen fragen Linienflaggen. Passiert mit oder ohne "verbose": true

Ich teile meine Beobachtungen zu console.log(), die beim Ausführen von Tests mit Jest nicht angezeigt werden.

Voraussetzung dafür ist das Ausführen von Jest mit dem --verbose Flag.

Wenn Sie Tests mit mehreren Testdateien ausführen, ist die Ausgabe von console.log() (meistens) nicht sichtbar.
Wenn Jest Tests aus nur einer Testdatei ausführt, funktioniert console.log() wie erwartet.

Sie können dieses Problem umgehen, indem Sie:

• Führen Sie Jest-Tests von nur einer Datei aus. Yup ... überhaupt nicht realistisch, also siehe nächste Option.
• Verwenden Sie das Flag --maxWorkers=1 . Irgendwie funktioniert das bei mir gut. Meine Vermutung(*) ist...Jest läuft im selben Prozess und es besteht keine Notwendigkeit, stdout von jedem Prozess zu puffern, um sie zurück zum Hauptprozess zu leiten.

Wenn meine Vermutung (*) ein erwartetes Verhalten ist, schlage ich vor, die Dokumentation zu aktualisieren, um dies deutlich anzuzeigen, um zu vermeiden, dass Entwickler Zeit damit verschwenden, herauszufinden, "warum meine console.log() manchmal nicht angezeigt wird".

Okay, das ist für einige Leute, mich eingeschlossen, heute immer noch ein Thema. Ich kann mir vorstellen, dass es auch weiterhin so bleibt.

Nach meinen Tests beendet Jest den Prozess, bevor er Protokolle ausgibt, was bedeutet, dass es so aussieht, als würden die Protokolle verschluckt.

Für mich setze ich verbose: true und bail: false in meiner jest-Konfiguration. Jest fährt fort, bis alle Tests ausgeführt wurden und gibt alle Fehler und Protokolle aus. Dies ist günstig. Ich habe auch --runInBand , was dasselbe wie die Einstellung von --maxWorkers=1 bewirkt.

Die größte Hilfe war bail: false denn so konnten alle Tests bis zum Abschluss ausgeführt werden. Es wurde immer noch mit dem Code 1 aber ich kann alle Protokolle wieder sehen.

Ausführen von Jest v19.0.2 mit Knoten v8.1.4.

Das Ausführen von --verbose --testPathPattern=<path/to/file> führte dazu, dass Protokolle gedruckt wurden. Andernfalls wird es verschluckt.

Kann jemand eine kleine Reproduktion bereitstellen, die auf jest 21.2.0 und aktuellen Knoten (also 4.8.4, 6.11.4 oder 8.7.0) fehlschlägt?

Es ist nicht erforderlich, verbose oder zusätzliche Jest-Konfigurationen zu konfigurieren, und das Problem ist einfach weg, wenn ich meine Knotenversion von 7.4.0 auf 8.0.0 aktualisiere. Das sind meine Beobachtungen.

Verwenden von [email protected]

Das ist SO frustrierend! Ich habe die neuesten Versionen von allem und Jest hackt immer noch die Ausgabe von console.log an scheinbar zufälligen Stellen ab. Dies macht es sehr schwierig, fehlgeschlagene Tests zu debuggen.

Ich habe gerade die Antwort darauf gefunden! Wenn Sie den ausführlichen Modus deaktivieren, wird die gesamte console.log-Ausgabe angezeigt! Ich denke, wenn Jest-Ausgaben ausführliches Zeug sind, wird es über Ihre Ausgabe der letzten paar console.logs geschrieben.

Haben Sie einen Code, der dies konsequent reproduziert? Könnte uns helfen, die zugrunde liegende Inkonsistenz zu beseitigen, die das Problem verursacht.

Ich habe expect(<value>).toEqual("someImpossibleValue") mit bail: false , um dies zu umgehen, wenn ich nur versuche, etwas kaputtes zu reparieren. Definitiv nicht ideal, aber schnell und schmutzig...

Vielleicht könnten Sie eine Funktion von Expect() einführen, die der von Expect() ähnelt, aber nicht abstürzt.

laufe v 22.0.4 ohne console.log.... füge dies zu einem von vielen anderen Gründen hinzu, warum ich es nicht empfehlen kann je

@mvolkmann danke für den Hinweis zum ausführlichen Modus. Wenn der nicht ausführliche Modus im Scherz die Standardeinstellung ist, könnte es sich lohnen, eine Änderung in Betracht zu ziehen. Es scheint mir nicht intuitiv, dass console.logs, die Sie in Ihren Code einfügen, einfach nicht angezeigt werden. Es ist das allererste und grundlegendste, was man versucht, wenn ein Test fehlschlägt.

(node ​​v9.3.0 und jest v20.0.4 hier)

jest ^21.2.1 und node 8.9.4

Jest wirft manchmal immer noch keine Konsolenprotokolle aus, die Option --verbose löst das Problem für mich nicht. Ich verstehe nicht, warum dieses Thema geschlossen ist.

@fega da niemand einen Reproduktionskoffer zur Verfügung gestellt hat, an dem wir ziehen und testen können.

$ jest --verbose

Dieser Befehl zeigt alle Konsolenprotokolle an

@odykyi funktioniert bei mir nicht. Witz 22.1.0 und v8.9.4

seltsames Verhalten. Wenn ich verbose auf false setze, wurden meine console.log-Anweisungen ausgegeben.

auf [email protected] , [email protected] und mit --forceExit sehe ich die Ausgabe von console.log aus meinem getesteten Code nicht, es sei denn, ich setze explizit verbose zu false oder entferne das --forceExit Flag (das ich vorübergehend verwende).

auf [email protected] , [email protected] und mit --forceExit sehe ich die Ausgabe von console.log aus meinem getesteten Code nicht, es sei denn, ich setze verbose explizit auf false oder entferne das Flag --forceExit (was Ich benutze vorübergehend).

Ich sehe genau das gleiche Verhalten wie oben beschrieben. [email protected] , [email protected].

console.logging, bevor done() aufgerufen wird, aber die Ausgabe wird nicht mit --forceExit angezeigt. Wenn --forceExit entfernt wird, wird die Ausgabe von console.log am Ende angezeigt.

Test Suites: 1 passed, 1 total
Tests:       35 skipped, 1 passed, 36 total
Snapshots:   0 total
Time:        2.512s
Ran all test suites matching /test\/api.test.js/i.
  console.log test/api.test.js:247
    bar

Ist also hier nicht die offensichtliche Lösung, um das Beenden von Flush zu erzwingen, was auch immer der Ausgabepuffer intern hat?

Wir haben einen Testfall dafür: https://github.com/facebook/jest/blob/497be7627ef851c947da830d4a8e21046f847a78/integration-tests/__tests__/console_log_output_when_run_in_band.test.js#L24 Ist es irgendwie defekt?

Kann jemand ein Reproduktions-Repository einrichten, das wir uns ansehen können?

Schnelle Ergänzung: jest --no-cache scheint auch zu bedeuten, dass console.logs nicht angezeigt werden.

Mit Node 9.7.1 und jest 22.4.2 mit babel 7 scheint die Verwendung von Verbose gut zu funktionieren, um Konsolenprotokolle aus Tests heraus anzuzeigen:

Paket.json

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

Es ist schon einige Zeit her, seit dies kein Eingreifen des Benutzers erforderte, aber es scheint, dass die Abhilfe konsistent war.

Dieses Problem quält uns auch schon seit einiger Zeit, zuerst wurde die Ausgabe zufällig abgeschnitten, jetzt wurde die Ausgabe völlig ignoriert. Klonen Sie zum Reproduzieren den Zweig dev/dexie-search-index dieses Repositorys:
[email protected] :WorldBrain/Memex.git

Fügen Sie diese Zeile irgendwo in insertTestData() in src/search/index.test.ts hinzu:
console.log('!?!?!?!!?!?!!?'); expect(1).toBe(2)

Getestet mit Node.js-Versionen 6.11 und 8.10. Bitte lösen Sie dies so schnell wie möglich, da dies das Codieren so viel langsamer macht :(

@frankred danke. Ich habe verbose: "false" und es funktioniert.

Stolperte gestern über dieses Problem https://github.com/evanw/node-source-map-support/issues/207 und es schien diesem Problem hier schrecklich ähnlich zu sein.

Dies ist problematisch, weil Schreibvorgänge in process.stdout in Node.js manchmal asynchron sind und über mehrere Ticks der Node.js-Ereignisschleife erfolgen können. Der Aufruf von process.exit() zwingt den Prozess jedoch zum Beenden, bevor diese zusätzlichen Schreibvorgänge in stdout ausgeführt werden können.

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

Ich habe den Code nicht überprüft, aber wenn process.exit() mit --forceExit , würde dies erklären, warum die Protokollausgabe verloren geht.

Habe gerade eine Lösung hinzugefügt, die bei diesem verwandten Problem für mich funktioniert hat: https://github.com/facebook/jest/issues/3853#issuecomment -375183943

@ledbit Das hat bei mir nicht funktioniert. Wow, ein Problem, das sich über anderthalb Jahre erstreckt und immer noch keine Lösung hat.

Das stimmt, aber es gibt immer noch nicht viel für die Entwickler.

Ich habe dieses Problem am häufigsten in einem verschachtelten asynchronen Aufruf in einem asynchronen Beispiel festgestellt. Ich bin mir nicht ganz sicher, ob dies bei anderen der Fall ist, aber die Verwendung von console.log wäre sicherlich hilfreich, um das Problem zu lösen.

Bei mir passiert es auf jeden Fall. Was brauchst du von mir, damit du es reparieren kannst?

Am 22. März 2018 um 8:32 Uhr schrieb Dennis Brown [email protected] :

Das stimmt, aber es gibt immer noch nicht viel für die Entwickler.

Ich habe dieses Problem am häufigsten in einem verschachtelten asynchronen Aufruf in einem asynchronen Beispiel festgestellt. Ich bin mir nicht ganz sicher, ob dies bei anderen der Fall ist, aber die Verwendung von console.log wäre sicherlich hilfreich, um das Problem zu lösen.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/facebook/jest/issues/2441#issuecomment-375349444 an oder schalten Sie den Thread stumm https://github.com/notifications/unsubscribe-auth/ADrayIO4NBB2dZM1XL8ZQO32W9SUnu2Yks5tg8 .

Noch besser, mach es! Hier ist mein Repo. https://github.com/RALifeCoach/handandfootserver.git

Führen Sie jest über npm oder über die Befehlszeile aus. Sie werden sehen, dass es viele, viele console.logs gibt, aber die meisten sind verdeckt.

Dort - das Entwicklerteam hat alles, was es braucht. Bitte beheben Sie dieses Problem.

Am 22. März 2018 um 8:36 Uhr schrieb Christopher Oliphant [email protected] :

Bei mir passiert es auf jeden Fall. Was brauchst du von mir, damit du es reparieren kannst?

Am 22. März 2018 um 8:32 Uhr schrieb Dennis Brown < [email protected] [email protected] >:

Das stimmt, aber es gibt immer noch nicht viel für die Entwickler.

Ich habe dieses Problem am häufigsten in einem verschachtelten asynchronen Aufruf in einem asynchronen Beispiel festgestellt. Ich bin mir nicht ganz sicher, ob dies bei anderen der Fall ist, aber die Verwendung von console.log wäre sicherlich hilfreich, um das Problem zu lösen.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/facebook/jest/issues/2441#issuecomment-375349444 an oder schalten Sie den Thread stumm https://github.com/notifications/unsubscribe-auth/ADrayIO4NBB2dZM1XL8ZQO32W9SUnu2Yks5tg8 .

@RALifeCoach Wenn Sie sich jetzt Ihr Repo geloggt . Darf man darauf hinweisen, welche Protokollierung Ihnen besonders fehlt?

Starte es. Sie werden einige Ausgaben sehen, aber vieles wird überschrieben.

Am Sa, 14.04.2018, 03:10 Uhr Simen Bekkhus [email protected]
schrieb:

@RALifeCoach https://github.com/RALifeCoach Betrachten Sie jetzt Ihr Repo,
dort wird ziemlich viel geloggt. Beachten Sie, welche Anmeldung
insbesondere fehlt dir?

—
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/2441#issuecomment-381318608 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ADrayHQCc8C0NmMmrtE7mEo2jN999CChks5tocsKgaJpZM4LVbUv
.

Ich bin mir nicht sicher, was du mit überschrieben meinst. Wird dann etwas an die Konsole ausgegeben?

Wenn mit console.log sechs Zeilen geschrieben werden, erscheinen die 6 kurz und dann
die Testzusammenfassung überlappt einige der 6 Zeilen.

Am Sa, 14.04.2018, 08:58 Uhr Simen Bekkhus [email protected]
schrieb:

Ich bin mir nicht sicher, was du mit überschrieben meinst. Wird etwas an die ausgegeben
Konsole dann gelöscht?

—
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/2441#issuecomment-381339074 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ADrayF0P5SqpHjaAAYcPaIAF7ubSMVRTks5tohyIgaJpZM4LVbUv
.

Ich erlebe auch, was @RALifeCoach beschreibt. Ich sehe, wie meine Protokollausgabe auf dem Bildschirm blinkt, während die Tests ausgelöst werden. Wenn ich dann nach oben scrolle, ist diese Ausgabe nicht mehr vorhanden.

Scheint, als ob dies immer noch ein Problem ist, selbst auf Knoten 8.11.1. Vielleicht sollten wir einen neuen Fehler melden und hier zurückgreifen?

Habe immer noch das gleiche Problem in Knoten v8.9.0.

Ich kann den Kommentar von @RALifeCoach bestätigen, angezeigt , indem ich jedes 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 abschließende Testzusammenfassung), aber es ist das einzige, was bisher funktioniert hat. Alles andere habe ich in den Kommentaren oben versucht. Beachten Sie, dass das Argument --verbose für diese Lösung erforderlich ist (und implizit über react-scripts mit --watch kombiniert wird).

[Verwenden von react-scripts gegabelt, um die neueste Jest v23.0.0, Knoten v8.11.2 zu verwenden]

Das Einrichten von "verbose": true in package.json hilft. Protokolle werden unten in der Ausgabe angezeigt.

Mann für ein geschlossenes Problem Ich sehe immer noch zu, wie sich Leute darüber beschweren, da es vor 2 Jahren erstellt wurde.

Ich denke, es gibt Code in Jest, der uns einen Spaß macht und console.log() "entführt".
es zu einem No-Op machen, so etwas wie...

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

Das Mittel zum Zurücksetzen von console.log ist ironischerweise - siehe https://stackoverflow.com/questions/7089443/restoring-console-log
-- Konsole.log löschen

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

...und plötzlich -- Voila! -- wie ein Phönix aus den Flammen -- console.log() funktioniert wieder in Jest...!
Jest druckt sogar "console.log (location info)" aus, bevor er deine Nachricht protokolliert...

>

console.log __tests__\libarray-helpers.test.js:35
Kannst du mich jetzt hören, Narren...?

Außerdem habe ich in letzter Zeit isomorphes "logatim" verwendet https://www.npmjs.com/package/logatim anstelle von console.log(), und es
scheint immun gegen Jests Entführungsversuche zu sein ... (vielleicht setzt es console.log zurück ...)

Sie können sich sogar präventiv console.log für logatim "entführen"
um eine "Info"-Level-Nachricht in Grün zu protokollieren...

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

(Bitte interpretiere meine Heiterkeit nicht als Kampflust...wo ist die Freude, ein gutes Produkt zu nennen, Scherz, wenn du nicht darüber scherzen kannst, Scherz ein bisschen...)

Bevor Sie Hass verbreiten, @yanshuf0 ,

Ich hatte dieses "Überschreiben" -Problem (Windows 10, VS Code-Terminal, node.js-Projekt) und dann, als ich daran herumfummelte, trat der Fehler nicht mehr auf. Ich dachte, es passiert nicht mehr, weil ich aufgehört habe, --watch oder weil ich eine Option "verbose": false hinzugefügt habe, aber das Zurücksetzen dieser Änderungen führte nicht dazu, dass der Fehler zurückkehrte.

Ich muss jedoch fragen, ob Jest die Protokollausgabe absichtlich nicht mit dem Test in Verbindung bringt, der sie erzeugt hat? Eine Zeitlang lag die gesamte Konsolenausgabe unter allen Testergebnissen, aber jetzt wird sie über allen Testergebnissen angezeigt. So zufällig.

--watchAll Flag hat es blockiert. jetzt funktioniert es bei mir

Nach monatelangem Scherz ist mir das mit Knoten 8.9 auch aus heiterem Himmel passiert. In einer Minute wurde console.log einwandfrei ausgegeben, in der nächsten funktionierte es einfach nicht mehr. Ich bin auf diesen Thread gelandet und habe ein paar Dinge ausprobiert. Wenn ich --watch das Problem behoben, aber dann musste ich meinen Testbefehl jedes Mal erneut ausführen. Die Verwendung von --watch --verbose false das Problem behoben und meine Tests automatisch ausgeführt.

Finde das gleiche Problem hier, danke für die vorübergehende Lösung @bkempner

Kann bestätigen, dass dies sowohl in 22.4.4 als auch in 23.4.1 (aktuell zum Zeitpunkt dieses Kommentars) ein Problem ist. Die von mir verwendeten Flags sind:

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

Ein weiteres Problem zum gleichen Thema schlug vor, die Option --json hinzuzufügen, die eine Zeit lang funktionierte ... Vielleicht hat sich seitdem einige Abhängigkeit geändert, aber die Ausgabe von STDOUT und STDERR wird immer unterdrückt. Am nächsten kam ich zu allem, was funktionierte, indem ich --watch benutzte; manchmal wurde eine Ausgabe an das Ende geheftet, ohne überschrieben zu werden.

Ich habe festgestellt, dass --silent standardmäßig true ist. Wenn Sie es auf false setzen, wird das console.log ausgegeben: jest --silent=false

Es scheint immer noch eine Menge Berichte darüber zu geben, etwas ist eindeutig immer noch kaputt. Dies wurde als Duplikat von #2166 geschlossen, das jetzt geschlossen ist, aber das bleibt bestehen.

@thymikee Könnten wir dieses Problem erneut öffnen?

Ich öffne dies erneut, da das Problem teilweise wieder da ist und wir es beheben müssen.

In v23 tritt das Problem im Watch-Modus auf, da wir die Funktionsweise unter der Haube geändert haben, um Tests fast immer parallel auszuführen, damit das TTY nicht blockiert wird und man lange laufende Tests einfach abbrechen kann: https://github. com/facebook/jest/pull/6647.
Der einzige Fall, in dem wir keine Arbeiter im Watch-Modus spawnen, ist, wenn wir genau einen Test ausführen müssen und dieser relativ schnell ist (unter 1s) – in diesem Fall sollten wir immer noch console.log s wie immer erscheinen sehen.

In meinem Fall hat alle Tests im Watch - Modus ordnungsgemäß ausgeführt wird loggt sein . Wenn ich den Mustermodus verwende, um nur nach einer Testklasse zu filtern, wird die Protokollierung abgeschnitten

Gemäß dem Kommentar von verbose: true in my package.json und Entfernen von --verbose aus meinem Befehlszeilen-Flags ermöglichen es mir, Konsolenprotokolle anzuzeigen, die ansonsten verborgen waren. Das ist ziemlich verwirrend.

Ich habe verbose: true in meinem package.json und ich stelle fest, dass console.log Anweisungen manchmal vorhanden sind und manchmal nicht (wenn ich insgesamt etwa 10 habe, scheinen sie aufzutauchen, aber nicht für nur einen) - Ich denke, das ist vielleicht ein asynchrones Problem

Ich habe dieses Problem auch gelegentlich, ich aktiviere runInBand (https://jestjs.io/docs/en/cli.html#runinband) und das behebt es.

@ndelangen das ist merkwürdig - ich frage mich, ob es dann vielleicht ein asynchrones Problem ist. Ich dachte, Jest sammelt alle console.logs und druckt sie dann am Ende aus, nicht wahr?

Das Problem tritt jetzt wieder auf, obwohl ich verbose .

--runInBand repariert es nicht für mich. Die einzige zuverlässige Problemumgehung besteht bisher darin, einfach etwas mehrmals zu protokollieren, damit ein Teil der Ausgabe nicht durch Scherze überschrieben wird.

Ich habe einige Analysen durchgeführt, einige Kommentare hinzugefügt und es geschafft, hier einen Teilpatch zu erstellen:

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

bearbeiten:

Repo mit Code zur einfachen Reproduktion hier verfügbar: https://github.com/spion/jest-logging-repro

Analyse der Ausgabe hier: https://gist.github.com/spion/bbb34c5abc1230a37ad5f4f01336b8df

Der Patch ist teilweise, weil

• viele Integrationstests scheitern jetzt aufgrund notwendiger Änderungen in der Ausgabe
• manchmal (leider) erscheint die Log-Ausgabe nach der letzten Statusaktualisierung - der Grund ist wahrscheinlich die Tatsache, dass die Kindprozessströme geleert werden, nachdem der Kindprozess die Erfolgsmeldung an den Elternteil gesendet hat.

@philraj gleiches Problem bei mir.. Ich muss mich mehrmals anmelden, um die beabsichtigte Protokollmeldung zuverlässig zu sehen

Warum ist das kein großes Problem und wird nicht so schnell wie möglich gelöst? Wie ist dieses Thema seit 2016 offen??

Update: Mit diesem Patch habe ich nur noch 8 fehlgeschlagene Tests:

diff --git a/packages/jest-runner/src/index.js b/packages/jest-runner/src/index.js
index 2f4dd724..618a8cbf 100644
--- a/packages/jest-runner/src/index.js
+++ b/packages/jest-runner/src/index.js
@@ -97,11 +97,14 @@ class TestRunner {
     // $FlowFixMe: class object is augmented with worker when instantiating.
     const worker: WorkerInterface = new Worker(TEST_WORKER_PATH, {
       exposedMethods: ['worker'],
-      forkOptions: {stdio: 'inherit'},
+      forkOptions: {stdio: 'pipe'},
       maxRetries: 3,
       numWorkers: this._globalConfig.maxWorkers,
     });

+    worker.getStdout().pipe(process.stdout);
+    worker.getStderr().pipe(process.stderr);
+
     const mutex = throat(this._globalConfig.maxWorkers);

     // Send test suites to workers continuously instead of all at once to track
diff --git a/packages/jest-worker/src/worker.js b/packages/jest-worker/src/worker.js
index 5eee64af..17d76d36 100644
--- a/packages/jest-worker/src/worker.js
+++ b/packages/jest-worker/src/worker.js
@@ -87,6 +87,13 @@ export default class {
   }

   _initialize() {
+    const forceColor =
+      'FORCE_COLOR' in process.env
+        ? process.env['FORCE_COLOR']
+        : // $FlowFixMe: Does not know about isTTY
+          process.stdout.isTTY
+          ? '1'
+          : '0';
     const child = childProcess.fork(
       require.resolve('./child'),
       // $FlowFixMe: Flow does not work well with Object.assign.
@@ -94,6 +101,7 @@ export default class {
         {
           cwd: process.cwd(),
           env: Object.assign({}, process.env, {
+            FORCE_COLOR: forceColor,
             JEST_WORKER_ID: this._options.workerId,
           }),
           // Suppress --debug / --inspect flags while preserving others (like --harmony).

Es geht hauptsächlich darum, FORCE_COLORS in process.env nicht zu erwarten, hg scm und packages/jest-runner/src/__tests__/test_runner.test.js die Streams nicht vollständig zu verspotten (also gibt es keine Pipe-Methoden für sie.

Bei diesem Tempo kann ich nächste Woche eine PR einreichen, die dies behebt ... vorausgesetzt, ich finde eine Lösung für die Protokollausgabe, die nach Abschluss des gesamten Berichts angezeigt wird.

Wie @bkempner sagte, behebt die Verwendung von --watch --verbose false das Problem.

Die Konsolenausgabe in --watch , die durch Scherzbewegungen des Cursors überschrieben wird, stimmt mit dem überein, was ich sehe. Das Vorhandensein/Fehlen von --verbose , --maxWorkers 1 , --runInBand führt nicht zum Erfolg.

Meine aktuelle Problemumgehung ist jest --watch | cat . Ich verliere alle Farben und bleibe oben im Fenster, aber ich erhalte die Konsolenausgabe.

Oder TERM=dumb jest --watch . Ich verliere das Bleiben am oberen Rand des Fensters, aber ich bekomme Farbe und die Konsolenausgabe.

Ich hatte das gleiche Problem.

Was für mich funktioniert hat, war console.debug

TERM=dumb behebt es auch für mich

FWIW, TERM=dumb behebt es auch für mich

das deaktivieren von verbose in der jest config hat bei mir funktioniert 0_o\

Das Hinzufügen von --verbose false zum package.json "test"-Skript hat das Problem für mich gelöst. Ohne diesen Thread hätte ich das nie gefunden.

z.B

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

Seltsam, wie einige der letzten Konsolen verschwinden, aber nicht alle, mit --verbose false in meinem Watch-Befehl behoben.

Funktioniert gut, wenn Sie ohne --watch ausführen, also liegt es an der Watch-Flagge, die es tut.

Das Ironische daran ist, dass es ausführlicher ist, wenn console.log funktioniert!

Ich habe dieses Problem mit ausführlichen Informationen in Jest 23.6 bemerkt, ich habe es auf 23.5 zurückgesetzt und sehe es immer noch. Wenn ich --clearCache ausführe, wird dies für eine Weile ausführlich behoben, bis es erneut fehlschlägt. Mir ist unklar, was der Auslöser ist, z. B. viele Protokollfehler oder etwas in dieser Richtung. Sobald dies geschieht, scheint Jest den Cache zu beschädigen. Ich versuche das --verbose false und schaue, ob das verhindert, dass es weitergeht.

Danke @jamespolanco Die Verwendung der Option --clearCache das Problem für mich (vorerst) behoben. Ich werde meine Tests mit der Option --no-cache ausführen und prüfen, ob dies verhindert, dass das Problem in Zukunft erneut auftritt.

EDIT: Ich hätte erwähnen sollen, dass mein Problem darin bestand, dass nur einige meiner console.log Nachrichten ausgedruckt wurden. Ich habe in einem Test 5 console.log Zeilen verwendet und nur die ersten 3 Zeilen wurden gedruckt. Die Verwendung von --clearCache dieses Problem für mich behoben. Vielleicht gibt es ein anderes Problem, bei dem keine console.log s angezeigt werden?

Ich habe dieses Problem auch. Ich habe versucht, console.log, console.debug und console.error zu verwenden. Ich habe auch versucht, das Flag --no-cache zu verwenden. In allen Fällen wird meine Konsolenanweisung komplett ignoriert.

Ich habe dieses Problem auch im Watch-Modus. Version 23.6.0

Ich habe es sogar aufgenommen, falls es jemand gerne selbst sehen möchte:

wie andere - wird es nur gelöscht, wenn es mit --watch . Habe es mit --verbose false versucht und das hat nicht geholfen.

Ich habe auch das gleiche Problem.

Ich erlebe dies auch, wenn ich ausführlich oder im Watch-Modus arbeite

Ob Sie es glauben oder nicht, ich melde mich manchmal, wenn ich einen Fehler werfe. Auch das Ausführen von node --inspect node_modules/.bin/jest --runInBand mypath/to/my.test.js zeigt in meinem Fall die echten console.log Ausgaben.

Knoten v9.11.1
Witz: v23.6.0

Jest-Konfiguration in package.json :

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

Ich bestätige, dass dieses Problem ausführlich ist. Das Problem besteht darin, dass die Berechnung der Zeilenanzahl durcheinander gebracht wird, wenn die Verbose-Funktion aktiviert ist.

Wenn mir jemand die Stelle zeigen kann, an der die Nachricht gedruckt wird, kann ich es versuchen.

Sie können die Ausgabe vorerst mit jest-watch-toggle-config mildern.

Richten Sie es so ein:

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

Wenn Sie Ihren Test ausführen, drücken Sie v , um die ausführliche Sprache zu v , um sie zu

Danach können Sie alle Protokolle sehen, solange Sie die Ausführlichkeit deaktivieren.

--verbose=false das Problem für mich behoben, als ich das Enzym seicht testete. Die console.logs waren, aber ohne das Update arbeitet für das Enzym montieren.

Dies deutet auf einen Unterschied zwischen der Protokollierung der Fehler durch den React-Test-Renderer und der Protokollierung durch den integrierten Renderer von React hin (da Enzyme überhaupt nicht mit Konsolenfunktionen spielen).

Zu Ihrer Information, diese PR behebt das Problem für mich - https://github.com/facebook/jest/pull/6871

Es ist noch nicht fertig, es könnte eine Änderung des Ansatzes erforderlich sein - aber es zeigt alle protokollierten Daten im ausführlichen Modus an.

Noch nicht aktualisiert (jest 22.4.2 ausgeführt), aber im Überwachungsmodus würden meine Protokolle nicht angezeigt. Beim Ausführen mit --runInBand es im Watch-Modus behoben.

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

Ich habe auch nicht aktualisiert (Jest 23.6.0), und das Ausführen mit "jest --watch --verbose=false" behebt es auch für mich.

Würde mich freuen, wenn Leute Probleme haben, die oben erwähnte PR zu testen. Es ist verfügbar in jest@beta ( 24.0.0-alpha.9 gerade)

Also Garn jest@beta hinzufügen

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

Würde mich freuen, wenn Leute Probleme haben, die oben erwähnte PR zu testen. Es ist
verfügbar in jest@beta (jetzt 24.0.0-alpha.9)

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/facebook/jest/issues/2441#issuecomment-448641697 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAM5P7ijQjSbWB0-zzDCfC9Uggyk5RGoks5u6l9EgaJpZM4LVbUv
.

>

Tarjei Huse
Mobil: 920 63 413

@tarjei , ja:

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

Bei mir funktioniert es. 🎉

Das ist wirklich albern, aber nur für den Fall, dass es anderen hilft, arbeite ich an einem neuen (für mich) Projekt - jest lief mit der Option --silent die die Ausgabe deaktiviert. Das wurde entfernt und ich sehe jetzt Protokolle 🤦‍♂️

Beachten Sie, dass ein Teil des Konsolenprotokolls in der Beta-Version blockiert wird, wenn die Ausführlichkeit aktiviert ist (ich schalte es mit jest-watch-toggle-config ).

--verbose=false

Das hat bei mir funktioniert.

Mir ist aufgefallen, dass einige console.log() funktionierten, während andere in meinen Tests nicht funktionierten (node ​​v8, [email protected]).

const something = () => new Promise(resolve => {
  console.log('NOT logged for some reason!')
  setTimeout(resolve, 100);
});

describe('Something', () => {
  it('logging works in non-async test', function () {
    console.log('logged 1')
    console.log('logged 2')
    expect(true).toBe(true);
  });

  it('console log does not work well in async test', async () => {
    console.log('logged 3')
    await something();
    console.log('NOT logged!')
    expect(true).toBe(true);
  });
});

/* Output:
> logged 1
> logged 2
> logged 3
*/

Es passiert etwas sehr Seltsames, bei async Tests, bei denen die ersten console.log im asynchronen Test nicht protokolliert werden, auch der nach den await wird nicht protokolliert.

Fügen Sie noch mehr console.log in diesem async Test hinzu und Sie werden ein noch seltsameres Verhalten bemerken, wie einige der Protokolle, nachdem das await plötzlich funktioniert hat 🤷‍♀️ 🤷‍♂️

Also, was @philwhln vor zwei Jahren oben geschrieben hat

Da ich dies nicht in einem einfachen Test isolieren kann, vermute ich, dass es etwas mit der Ausführung eines komplexeren asynchronen Tests zu tun hat.

Scheint etwas Wahres zu sein.

--verbose=false

Hat in diesem Fall auch bei mir funktioniert.

@DanweDE können Sie überprüfen, ob die neueste Alpha- yarn add jest<strong i="6">@beta</strong> --dev das Problem für Sie behebt, selbst wenn die ausführliche Version auf true ?

Das Hinzufügen von --verbose false das Problem behoben. Das scheint ein bisschen unintuitiv zu sein :)

Ist das behoben? Ich sehe immer noch keine console.logs auf "Jest": "23.6.0"

@iDVB Wenn Sie den Thread ein paar Kommentare oben lesen, sehen Sie, dass es eine Beta-Version gibt, die das Problem beheben soll. Probieren Sie es aus und melden Sie, wenn es Ihr Problem löst, um @spion zu helfen

Auch alle, die hierher kommen, um --verbose false oder --verbose true oder eine beliebige Kombination von Flags oder Node- oder Jest-Versionen zu sagen, haben ihr Problem behoben.

Konsolenprotokolle in den Klassen, die ich teste, werden angezeigt

@philraj wir sind bei @leaplabs auf die Beta-Version "24.0.0-alpha.9" umgestiegen und sie funktioniert einwandfrei. In dem Sinne, dass seit dem Upgrade keine Protokolle verschwunden sind.

Kann auch bestätigen, funktioniert auf 24.0.0-alpha.9 ohne irgendwelche Kommandozeilen-Argumente.

Ich bin relativ neu bei React und Jest. Ich konnte keine konsistenten Protokolle mit den Standardeinstellungen von create-react-app abrufen. Ich habe ausgeworfen und jetzt funktionieren die Protokolle einwandfrei. Ich glaube nicht, dass das Auswerfen die Version von Jest geändert hat. Vielleicht hat sich dadurch nur eine der Einstellungen für die Ausführung von Jest geändert. Dies ist mit 23.6.0 .

Wenn ich 24.0.0-alpha.16 sehe ich keine Konsolenprotokolle, es sei denn, ich füge verbose=false .

Auch damit erhalte ich auf [email protected] ziemlich inkonsistente Ergebnisse

--verbose=false das auch für mich behoben 🎉

Ich verwende 24.1.0 und es funktioniert auch ohne ausführliche Option. Es werden jedoch keine console.log Anweisungen in der Testdatei ausgegeben, wenn die Testdatei z. Referenz auf Klasse, die nicht importiert wird. Beispielsweise

Das ist ein Fehler von ts-jest und hier nicht wirklich relevant

Ja, aber wenn dieser Fehler auftritt, wird die Konsolenprotokollausgabe nicht angezeigt. Ist das für ts-jest noch relevant? Ich bin nicht sehr vertraut damit, wofür jede Bibliothek rund um Jest verantwortlich ist.

IDK, wie ts-jest funktioniert, aber wenn es keine Tests auf Typfehler ausführt, würde dies erklären, warum sie fehlen - der Code wird nie ausgeführt

Ich kämpfe immer noch darum, dass console.log hier arbeiten. Ich erhalte gelegentlich Protokolle, aber es scheint kein erkennbares Erfolgsmuster zu geben.

Ich benutze Jest 24.7.1 und habe auch 24.7.1 und 24.2.0-alpha.0 ausprobiert.

Das Setzen von verbose=false und verbose=true konnte beide keine Lösung bereitstellen.

Ich habe auch versucht, die Knoten v10.8.0 und v6.17.1 , ebenfalls ohne Fix.

Fehlt hier etwas?

@mulholio sind Sie zu 100% sicher, dass Sie lokal installierten Scherz ausführen? Ich habe in der Vergangenheit Probleme gemeldet, die nur auftraten, weil ich eine alte globale Version eines Pakets hatte, die anstelle der lokal installierten lief.

Ja, keine globalen Versionen von Jest installiert

Ich kann bestätigen, dass es nicht behoben wurde. manchmal funktioniert console.log und manchmal nicht, wie verwirrt mich.
meine Umgebung wie folgt:
Witz 23.6.0
Knoten v8.13.0
und meine jest.config.js

const path = require('path');

module.exports = {
  moduleNameMapper: {
    "\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$": "<rootDir>/__mocks__/fileMock.js",
    "\\.(less|css|scss)$": "<rootDir>/__mocks__/cssMock.js",
    "^@\/(.*)$": "<rootDir>/src/client/$1",
  },
  bail: true,
  setupTestFrameworkScriptFile: "<rootDir>/setupTests.js",
  collectCoverageFrom: [
    "src/client/**/*.{js,jsx}",
  ],
  verbose: true,
  coverageReporters: ["text", "text-summary", "lcov", "json"],
  coveragePathIgnorePatterns: ["src/client/index.js"],
}

ja, nach dem Entfernen von verbose:true scheint es in Ordnung zu sein

Ich sehe diesen Fehler auch, können wir dieses Problem erneut öffnen?

Zu Ihrer Information: Wenn ich fit , um einen einzelnen Test auszuführen, haben meine console.log s nichts ausgegeben. Als ich die ganze Reihe von Tests durchführte, funktionierten die console.log s einwandfrei.

Beim Auftreten des gleichen Problems werden einige Konsolenprotokolle "aufgefressen". Können Sie für diejenigen mit diesem Problem mehrere Konsolenprotokolle überprüfen, aber klonen?

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

Es sieht so aus, als würde der Puffer für die [PASS]-Anweisung die letzten 2 Konsolenprotokollzeilen überschreiben (ich kann einen Teil der Konsolenprotokollzeilennummer am Ende der Pass-Anweisung sehen)

+1000

Klingt wirklich albern, aber yarn build machen Sie vor den Tests!

Immer noch keine Ausgabe mit --verbose=true oder --verbose=false bei Verwendung von [email protected] - nicht sicher, warum es 3 Jahre nach der ursprünglichen Protokollierung immer noch ein Problem ist.

Haben Sie versucht, das Scherz-Flag --runInBand zu verwenden, um zu sehen, ob dies durch seriell ausgeführte Tests gelöst wird? Jemand hat mir das gesagt, hatte aber noch keine Gelegenheit, es zu testen.

Danke, es funktioniert! Aber warum nicht als Standard die Ausgabe von console.log festlegen..

Das ist immer noch ein Thema für mich, [email protected]

Ich habe tatsächlich eine Lösung gefunden, die letzten 2 Zeilen im letzten Testfall (aufsteigend) werden überschrieben, also machen Sie dies zu Ihrem letzten Testfall

it('bugfix for [email protected]', () => {
  console.log("[email protected] bug|last 2 lines get override. remove this once 24.8.0 gets fixed");
  console.log("[email protected] bug|last 2 lines get override. remove this once 24.8.0 gets fixed");
});

Für diejenigen, die ts-jest , musste ich die Diagnose deaktivieren, um die console.logs zu sehen
jest.config.js

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

Für diejenigen, die ts-jest , musste ich die Diagnose deaktivieren, um die console.logs zu sehen
jest.config.js

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

Diese Option hat bei uns nicht funktioniert. Wir haben auch versucht, verbose = false was auch nicht geholfen hat.

Unsere Umwelt:

• Knoten 10.16.0
• Witz 24.8.0
• ts-jest: 24.0.2
• Typoskript 3.5.2
• @types/jest 24.0.15

Es sieht so aus, als würde der Puffer für die [PASS]-Anweisung die letzten 2 Konsolenprotokollzeilen überschreiben (ich kann einen Teil der Konsolenprotokollzeilennummer am Ende der Pass-Anweisung sehen)

Dies scheint bei mir der Fall zu sein ([email protected]). Auf meinem System scheint die Terminalausgabezeile mit [PASS] einige Inhalte zu blinken, bevor sie gelöscht werden.

Erlebe dieses Problem auch.

Ich kann mich mit keiner der oben genannten Lösungen anmelden, aber als Problemumgehung erwarte ich nur, dass der Wert fehlschlägt und das Diff überprüft:

expect(thingIWantToLog).toBe({})

Ich bin auch darauf gestoßen: Es scheint, dass die Ausgabe von "PASS: ..." die Standardausgabe überschreibt, sodass Ihr "letztes" console.log gefressen wird.

Wenn --verbose=false nicht funktioniert, können Sie Ihrem letzten console.log eine Reihe von neuen Zeilen ( \n ) hinzufügen.

Haben Sie versucht, das Scherz-Flag --runInBand zu verwenden, um zu sehen, ob dies durch seriell ausgeführte Tests gelöst wird? Jemand hat mir das gesagt, hatte aber noch keine Gelegenheit, es zu testen.

Das Hinzufügen dieses Flags half, das Problem zu lösen.
Von Zeit zu Zeit wurden auch die Ausgaben von console.log nicht angezeigt.
Mit diesem Befehl:
npm test -- --verbose --runInBand -t "My Test Name"

Knoten- und NPM-Versionen:
node v8.16.0
npm 6.4.1

Das ist mein Workaround:

npm install --save-dev sprintf-js

Im Scherz setupTest.js oder wo auch immer:

import {sprintf} from 'sprintf-js';

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

Immer noch keine Ausgabe mit --verbose=true oder --verbose=false bei Verwendung von [email protected] - nicht sicher, warum es 3 Jahre nach der ursprünglichen Protokollierung immer noch ein Problem ist.

Das ist mein jest.config.js und es hat bei mir funktioniert.
jest -v 23.6.0 & node -v 8.11.2

module.exports = {
  clearMocks: true,
  moduleDirectories: [
    'node_modules',
  ],
  testEnvironment: 'node',
  testMatch: [
    '**/__tests__/**/*.js?(x)',
    '**/?(*.)+(spec|test).js?(x)',
  ],
  verbose: false,
};

Dann habe ich in package.json :

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

Führen Sie dann Ihre spezifische Testsuite mit diesem Befehl aus:

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

--verbose=false scheint bei mir funktioniert zu haben. Danke!

Verstecke die Protokolle und Warnungen, wenn du die Option --silent passierst
Versuchen Sie es mit yarn jest es sollte funktionieren

Dieser Fehler ist so nervig... 3 Jahre...

ausschalten --silent
und für ts-Tests mit ts-jest @mr-madamin-Lösung, die für mich funktioniert!

verbose oder silent , --runInBand , TERM=dumb ausprobiert, alle Tests vs. einzelne Testdatei ausgeführt haben und console.log erscheint, wenn in Setup-Blöcken platziert, aber nicht innerhalb von it() Blöcken.

Wenn alles andere fehlschlägt, sollten Sie immer noch in der Lage sein, Folgendes zu tun:

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

Aber ich fühle mich wie ein Höhlenmensch, der einen Stein benutzt, um eine Erdnuss zu knacken.

Bearbeiten: "jest": "^24.9.0"

Ich verwende diesen Befehl und er funktioniert:

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

Sie können Ihren Testnamen nach dem Flag -t angeben, um einzelne Tests oder Testgruppen unter demselben describe() auszuführen.

verbose oder silent , --runInBand , TERM=dumb ausprobiert, alle Tests vs. einzelne Testdatei ausgeführt haben und console.log erscheint, wenn in Setup-Blöcken platziert, aber nicht innerhalb von it() Blöcken.

Wenn alles andere fehlschlägt, sollten Sie immer noch in der Lage sein, Folgendes zu tun:

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

Aber ich fühle mich wie ein Höhlenmensch, der einen Stein benutzt, um eine Erdnuss zu knacken.

Bearbeiten: "jest": "^24.9.0"

Ich war aufgeregt, endlich mit der Verwendung von Scherz im Backend für Einheitlichkeit zu beginnen. Stattdessen stoße ich auf dieses Problem und wechsle ab sofort zurück zu Mokka / Proxy. Keine console.log Ausgabe sichtbar (in Modulen oder Testfällen) und nach mehreren Stunden damit scheint keine der Problemumgehungen zu helfen. Kein Interesse an Workarounds, die das Loggen in Dateien beinhalten...

Getestet gegen Knoten 8/10 LTS mit "jest": "^24.9.0",

Ja. Bin auch am Rand. Es scheint hier beliebter zu sein, das Problem zu schließen und Hacks zu empfehlen, anstatt offensichtliche Probleme für über 3 Jahre zu beheben.

Hallo samlevin und pavelloz,
Haben Sie diese Möglichkeit ausprobiert?

Ich verwende diesen Befehl und er funktioniert:
npm test -- --runInBand -t "My Test Name"

Sie können Ihren Testnamen nach dem Flag -t angeben, um einzelne Tests oder Testgruppen unter demselben describe() auszuführen.
Könnten Sie mir bitte mitteilen, ob es funktioniert? Da ich es seit einiger Zeit benutze.

Hier ist ein Screenshot mit einem Beispielcode und einer Ausgabe.
Beachten Sie Folgendes: Falls Sie es nicht wissen, wird die Datei console.lg über allen anderen Berichten gedruckt und nicht am Ende, wo der Codeabdeckungsbericht oder die Fehlerfortsetzung angezeigt wird.

Meine Node- und NPM-Versionen:

node v8.16.0
npm 6.4.1

Ich war aufgeregt, endlich mit der Verwendung von Scherz im Backend für Einheitlichkeit zu beginnen. Stattdessen stoße ich auf dieses Problem und wechsle ab sofort zurück zu Mokka / Proxy. Keine console.log Ausgabe sichtbar (in Modulen oder Testfällen) und nach mehreren Stunden damit scheint keine der Problemumgehungen zu helfen. Kein Interesse an Workarounds, die das Loggen in Dateien beinhalten...

Getestet gegen Knoten 8/10 LTS mit "jest": "^24.9.0",

Ich habe jede einzelne Lösung in diesem Thread getestet.

Nur um zu überprüfen, ob sich diesbezüglich nichts geändert hat:

bash-5.0$ npm -v ; node -v; cat node_modules/jest/package.json |grep version
6.12.0
v12.11.0
  "version": "24.9.0",

Bearbeiten

Beachten Sie Folgendes: Falls Sie es nicht wissen, wird die Datei console.lg über allen anderen Berichten gedruckt und nicht am Ende, wo der Codeabdeckungsbericht oder die Fehlerfortsetzung angezeigt wird.

Ich habe nicht einmal den unteren Rand des Berichts überprüft, aber genau dort ist mein Log gelandet. Also ich denke, es funktioniert, nur nicht konsistent / für alle gleich.

Danke für Ihre Hilfe.

Die Frage ist, wie sehr es die Leistung beeinträchtigt, aber für einen anderen Tag ist die Protokollierung wichtiger.

Sie haben Recht @pavelloz , wenn Sie die Tests mit der Option --runInBand länger , die Tests

--runInBand, -i                 Run all tests serially in the current process
                                  (rather than creating a worker pool of child
                                  processes that run tests). This is sometimes
                                  useful for debugging, but such use cases are
                                  pretty rare.

Was ich also mache, ist, diese Option nur zu verwenden, wenn ich ein Problem in einem Test debuggen muss.
In allen anderen Fällen führen Sie den Test einfach normal durch.

Beifall

const-Komponente = flach(...)
console.log(Komponente.debug())

Es ist unglaublich, dass dies noch nicht behoben wurde.

@ivandosreisandrade Ich konnte die runInBand überprüfen, aber zu diesem Zeitpunkt würde ich lieber keine Zeit damit verschwenden, den zusätzlichen Schritt für andere Entwickler hinzuzufügen, und bin zu etwas zurückgekehrt, das sich wie erwartet verhält. werde abonniert bleiben, um zu sehen, ob sich diesbezüglich etwas ändert

Ich habe alles in diesem Thread versucht und kann immer noch keine Ausgabe für console.log sehen. --runInBand löst das Problem bei mir nicht. Verwenden von node@12 und neuestem Scherz. Das Debuggen mit Webdev ist schwer genug, es wäre wirklich nützlich, wenn ich zumindest auf dem Bildschirm drucken könnte, um zu sehen, warum mein Komponententest fehlschlägt

@u84six hast du meine Lösung ausprobiert?
Hier ist der Link zu meiner Antwort auf den Beitrag.
https://github.com/facebook/jest/issues/2441#issuecomment -552368939

Beifall

@ivandosreisandrade Wenn ein Fehler im Code

@ivandosreisandrade wie sieht Ihre package.json aus? Ich versuche dem zu folgen:

npm test -- --runInBand -t "Mein Testname"

Aber ich habe es so in meinem package.json eingerichtet

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

Man könnte meinen, dass mit dem Flag --verbose eine console.log durchgelassen werden könnte, aber ich kann console.log immer noch nicht zum Laufen bringen. So frustrierend!

@ivandosreisandrade wie sieht Ihre package.json aus? Ich versuche dem zu folgen:

npm test -- --runInBand -t "Mein Testname"

Aber ich habe es so in meinem package.json eingerichtet

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

Man könnte meinen, dass mit dem Flag --verbose eine console.log durchgelassen werden könnte, aber ich kann console.log immer noch nicht zum Laufen bringen. So frustrierend!

@u84six das ist mein packadge.json

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

Ihr testMatch lässt entweder .js oder .jx oder .jsx Dateien zu, und Ihr ModulFileExtensions lässt nur .js . Da scheint etwas nicht zu stimmen.

Es ist nicht relevant für die Ursache :man_shrugging:
Dies ist nur die Datei, die Sie suchen und testen müssen.

Ich bin mir nicht sicher, warum das Thema geschlossen ist. Hier ist also meine Knotenversion - 13.12.10, npm -6.14.4
Witz -24.9.0

Hier ist ein grundlegender Test mit mock-fs
importiert Mock aus 'mock-fs';
import * als fs aus 'fs';
Pumpe aus 'Pumpe' importieren;
import * als util von 'util';

describe('Test suite for bucket functionality', () => {
    beforeEach(() => {
        mock({
            'sample-file.txt': 'Content of the sample file',
            'sample-upload.txt': ''
        });
    });
    test('test upload', async () => {
        const filePromisy = util.promisify(fs.readFile);
        pump(fs.createReadStream('sample-file.txt'), fs.createWriteStream('sample-upload.txt'));
        filePromisy('sample-upload.txt').then(data => {
                       // when I do a console.log() here I get a warning stating that before I do an expect of data , I get a warning (no longer an error) stating that -_Cannot log after tests are done._

        }).catch(err => {

        });



    });
    test('test download', () => {

    });
});

Ich bin mir nicht sicher, warum dies passiert. Liegt das an der Event-Schleife, bei der das console.log erst nach der Ausführung der Testspezifikationen als verarbeitet im nextTick() betrachtet wird. Entschuldigung, dass ich dies anspreche, aber es scheint ziemlich mühsam zu sein, jeden einzelnen Testfall zu debuggen, anstatt nur eine Konsolenoperation durchzuführen und die erforderlichen Daten zu überprüfen.

Weil Sie Ihr filePromisy-Versprechen zum Scherz zurückgeben müssen, damit es weiß, wann Ihr Test abgeschlossen ist - Ihr Problem hat damit nichts zu tun.

Ich habe dieses Problem zu Debugging-Zwecken umgangen, indem ich einfach alles, was ich wollte, in eine temporäre expect Anweisung eingegeben habe. Verwenden Sie also anstelle von console.log(sketchyVariable) expect(sketchyVariable).toEqual(42) .

Was bei mir auf Node 8 funktioniert hat:
Anstatt console.log , verwenden Sie das integrierte Debug-Protokoll:

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

Und starte Spaß mit dem Debugger-Flag:

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

Ich habe gesehen, dass Konsolenprotokolle sporadisch angezeigt werden, wenn ich einen einzelnen Test angesehen habe. Manchmal sah ich alle Protokolle, manchmal keine, und manchmal sah ich einige davon, aber nicht alle. Jedes Mal, wenn der Test lief, sah ich etwas anderes. 😒

--verbose=false es für mich behoben. Das hat mich überrascht, denn ich setze verbose true nirgendwo auf Jest es automatisch auf true , wenn Sie einen einzelnen Test ausführen. 🙃

Wenn nur eine Testdatei ausgeführt wird, wird sie standardmäßig auf "true" gesetzt.

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

Zugehöriger StackOverflow-Thread: https://stackoverflow.com/questions/48695717/console-log-statements-output-nothing-at-all-in-jest

Jest kann das Protokollieren auf mehreren Ebenen nicht gut handhaben. es sollte

• Erfassen und zeigen Sie standardmäßig alle erfassten Protokolle für einen Test bei Fehlern an
• die Option haben, überhaupt keine anzuzeigen, und
• haben eine Option zum Deaktivieren der Erfassung.

das ist es. nicht wirklich kompliziert.

Ich vermute, sie erfassen die Konsolenprotokolle, weil sie versuchen, beim Ausführen von Tests eine asynchrone Ausgabe in einer vernünftigen Reihenfolge zu drucken. Das Problem ist, dass, wenn dieser Protokollierungscode für einen Benutzer in seiner Umgebung nicht funktioniert, er ziemlich abgespritzt wird.

Ich habe vor Jahren aufgehört, Scherze zu verwenden, weil ich beim Debuggen von Tests keine zuverlässige Konsolenausgabe erhalten konnte, egal welchen Vorschlägen ich in diesem Thread gefolgt bin.

Die Moral der Geschichte lautet: Leg dich nicht mit der globalen Konsole an. IMMER. Wenn Sie einen Logger bereitstellen möchten, der sich hervorragend ein- oder ausschalten lässt, tun Sie dies. Ich werde es benutzen, wenn ich will. Aber in die globale Konsole sollte nicht eingegriffen werden.

Holen Sie sich Outlook für iOS https://aka.ms/o0ukef

Von: Earonesty [email protected]
Gesendet: Mittwoch, 12. August 2020 12:33:23
An: facebook/jest [email protected]
Cc: Chris Grimes [email protected] ; Erwähnen Sie Erwä[email protected]
Betreff: Re: [facebook/jest] console.log wird beim Ausführen von Tests nicht ausgegeben (#2441)

Jest kann das Protokollieren auf mehreren Ebenen nicht gut handhaben. Es sollte Protokolle erfassen und standardmäßig bei Fehlern anzeigen, eine Option haben, überhaupt keine anzuzeigen, und eine Option haben, alle anzuzeigen. das ist es.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/facebook/jest/issues/2441#issuecomment-673011577 an oder melden Sie sich ab https://github.com/notifications/unsubscribe-auth/AAFCNBK5MQEA6AJHEC52ZWDSALG6HANCNFSM4C2VWUXQ .

@halis Ich

Meiner Meinung nach besteht das Hauptaugenmerk von Jest darin, ab und zu das erwartete Verhalten und die Semantik zu brechen, wenn dies das Testerlebnis drastisch verbessert. Dinge wie das Autohoisting von jest.mock(...) bedeuten, dass Jest-Tests in ihrer Semantik nicht ausschließlich JavaScript (oder sogar ECMAScript) sind; Parallelität bedeutet ebenfalls, dass alle void-rückgebenden eingebauten Methoden wie console.log als asynchron behandelt werden können und sollten, wenn dies die Leistung verbessern kann.

Ist das etwas schlechtes? Natürlich nicht unbedingt, denn Jest ist enorm erfolgreich. Aber ich denke, Jest hat die Fähigkeit, Sie hin und wieder zu überraschen. Ich bin mir ziemlich sicher, dass 90% der Jest-Benutzer keine Ahnung haben, dass ihr Code beispielsweise AST-transformiert ist, um Scheinanrufe zu erheben.

Ich bin mir ziemlich sicher, dass 90% der Jest-Benutzer keine Ahnung haben, dass ihr Code beispielsweise AST-transformiert ist, um Scheinanrufe zu erheben.

WAS

Versuchen Sie es mit console.debug oder console.error

Sie können --useStderr in meinem Fall verwenden, um das Problem zu lösen, da Nachrichten direkt weitergeleitet werden

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

Ich habe heute wieder damit zu kämpfen und das --useStderr Flag hat es für mich behoben. Danke @diomalta!

Ich hatte mit dem gleichen Problem zu kämpfen, Protokolle wurden nicht angezeigt, wenn ein Test fehlgeschlagen ist.

Ich habe es geschafft, dass mein console.log angezeigt wird, indem ich jest.config verbose: true in meinem jest.config