Jest: console.log не выводится при запуске тестов

Созданный на 25 дек. 2016  ·  236Комментарии  ·  Источник: facebook/jest

Вы хотите запросить функцию или сообщить об ошибке ?

Сообщите об ошибке .

Каково текущее поведение?

Вызов console.log с использованием testEnvironment по умолчанию jsdom не выводит на стандартный вывод.

Если текущее поведение является ошибкой, пожалуйста, предоставьте шаги для воспроизведения и либо демонстрацию repl.it через https://repl.it/languages/jest, либо минимальный репозиторий на GitHub, в котором мы можем yarn install и yarn test .

  1. Клонировать https://github.com/udbhav/jest-test
  2. Выполнить yarn test
  3. Убедитесь, что вы ничего не видите в console.log
  4. Измените параметр конфигурации testEnvironment Jest на node
  5. Повторно запустить yarn test
  6. Убедитесь, что вы видите вывод из console.log

Какое ожидаемое поведение?

Я ожидал, что console.log всегда будет выводиться во время выполнения моих тестов.

Укажите точную конфигурацию Jest и укажите свой Jest, узел, версию yarn / npm и операционную систему.

См. package.json и yarn.lock в репозитории для версий пакетов. Я использую узел 7.3.0 и пряжу 0.18.1

Самый полезный комментарий

Я использую node v4.4.7, и, насколько мне известно, отсутствие вывода на стандартный вывод при использовании console.log является проблемой. Я не пытаюсь помочь с кодированием, я сообщаю о том, что мне кажется ошибкой. Единственное, что изменилось, это то, что раньше у меня было запущено несколько тестовых файлов, а теперь только один. позвольте мне увидеть, если повторное включение других тестов снова приведет к появлению выходов console.log .

Все 236 Комментарий

Просто протестировал это с помощью repl.it: https://repl.it/EwfT/0

Хорошая новость в том, что он работает, как ожидалось, и выводит console.log. Я попытался понизить свою версию шутки до 17.0.3, но все еще видел те же проблемы. Установлен nvm для тестирования с узлом v6.9.2, и ура console.log работает с jsdom, поэтому я предполагаю, что проблема связана с узлом v7.

Спасибо, что сообщили об этом, но это дубликат # 2166 и тоже происходит на узле 6.

@thymikee Как это дубликат № 2166? В этом сценарии console.log вообще ничего не выводит. У меня проблема с Node v4. Разочаровывает то, что сегодня он работал нормально, и с нулевыми изменениями в моей среде я больше не получаю console.log выводов на свой терминал.

@thisissami, похоже, ваш тест или код не работает. Набор тестов Jest проходит через узлы 4 и 6, что гарантирует, что печать с консоли работает нормально, и мы работаем над исправлением для версии 7.3.

@cpojer - Мои тесты проходят / не проходят должным образом - просто сообщения console.log не отображаются. Я обнаружил это, когда пытался выяснить, каковы свойства конкретного объекта с помощью console.log , и не видел вывода. Я добавил много операторов console.log и сейчас ни один из них не отображается в моем терминале. = / Сейчас я возвращаюсь к Jest v17 чтобы посмотреть, изменится ли что-нибудь.

Если это работало для вас ранее сегодня и больше не работает, вы, должно быть, сделали обновление или что-то сломали. Мы не публиковали релиз Jest за две недели.

Хорошо, единственное, что изменилось в моем тестовом коде, - это то, что я добавил многострочный комментарий после кода, который должен запускаться (в качестве ссылки для себя). Я посмотрю, изменит ли это удаление.

@cpojer Я не знаю, что сказать, я не вижу ничего плохого в моем тестовом коде, но ничего не выводится на стандартный вывод:

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

Как и ожидалось, тест не прошел, поэтому я знаю, что он работает. Моя конфигурация в package.json действительно проста, исключительно:

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

Jest работал нормально, без дополнительных флагов. Та же проблема с Jest v17 и 18.

За весь день я не менял никаких файлов, кроме этого. Я только что начал понимать, как работает enzyme , выводя различные вещи в stdout , и после того, как начал добавлять expects , console.logs остановился работали, когда они мне снова понадобились, а теперь они совсем не работают - что бы я ни показал в тесте. Я тоже ничего не менял в своей среде (кроме перехода на версию 17), что, безусловно, сбивает с толку.

Похоже, вы обновились до узла 7.3. У нас есть кое-что для этого. Обратите внимание, что это средство отслеживания проблем не является справочным форумом; используйте stackoverflow для вопросов :)

Я использую node v4.4.7, и, насколько мне известно, отсутствие вывода на стандартный вывод при использовании console.log является проблемой. Я не пытаюсь помочь с кодированием, я сообщаю о том, что мне кажется ошибкой. Единственное, что изменилось, это то, что раньше у меня было запущено несколько тестовых файлов, а теперь только один. позвольте мне увидеть, если повторное включение других тестов снова приведет к появлению выходов console.log .

@cpojer Вполне уверен, что у вас, ребята, есть ошибка.

Выполнение 3 тестов (как в 3 разных файлах с .test.js , причем 2 из этих файлов являются примерами из ваших руководств) работает без проблем. Мой тест (скопированный выше) отображает все console.logs.

Выполнение всего 1 тестового прогона (я также переименовал .test.js в .teast.js в 2 файлах) не приводит к отображению выходных данных console.log.

Я собираюсь запустить второй произвольный тест, чтобы увидеть нужный мне результат, так что я годен для моих личных нужд - но это должно быть решено imo, предполагая, что он может быть воспроизведен где-нибудь в другом месте.

Набор тестов Jest проверяет это поведение на узле 4, узле 6 и узле 7.3. Он работает для 4 и 6, но был сломан в 7.3. Я исправляю это для узла 7.3 и вскоре опубликую новую версию Jest: https://github.com/facebook/jest/pull/2464

Если собственный набор тестов Jest, использующий узел 4, не подходит для вас, то, вероятно, что-то не так с вашей настройкой.

Клонировать репозиторий и попробовать сейчас.

Все прошло, кроме этих 3-х тестов. Не уверен, какие последствия это может иметь. У вас есть вся информация об ошибках, связанных с console.log, которые у меня есть, а также изображение ниже. Если это не шутка, то так тому и быть. Мне кажется странным, что ничего не делать, кроме следования руководствам, может привести к сценарию, когда я не вижу свои журналы при запуске только одного тестового файла.

screen shot 2016-12-28 at 5 55 29 pm

Это просто указывает на то, что у вас не установлен mercurial (hg), не связанный с вашей проблемой. Похоже, что набор тестов прошел за вас и, как сказано; мы явно тестируем поведение журнала в наборе тестов, поэтому должно быть что-то не так с вашим кодом или настройкой.

Хорошо, круто - спасибо за отзыв. Есть ли у вас какие-нибудь догадки относительно того, что могло заставить его работать, когда файлов несколько, а не только один? Если вам в голову не приходит очевидное «о, это иногда вызывает подобные проблемы» - не беспокойтесь, я просто гарантирую, что всегда будет запущено как минимум 2 файла. :)

У меня такая же проблема, console.log сейчас не выводится (а раньше это было около часа назад). Я использую узел 6.9.1, а также включаю флаг --forceExit. Когда у меня не включен этот флаг, появляется вывод console.log.

Однако у меня есть другой тестовый сценарий, который использует флаг --forceExit и появляется console.log, поэтому я не могу сказать, что флаг --forceExit вызывает такое поведение.

Как и @thisissami , у меня проблема с журналированием возникает только тогда, когда я пытаюсь протестировать отдельный файл.

У меня была такая же проблема, но я обнаружил, что это было связано с запуском jest через jest-cli (jest.runCLI) в gulpfile.js, и он проглатывал вывод console.log. Если я запускаю jest напрямую, я вижу вывод консоли.

Я сейчас наблюдаю какое-то странное поведение, которое я пока не могу изолировать от простого тестового примера, иначе я бы напишу новую проблему.

1) Jest запускает тест
2) Jest выводит операторы console.log (здесь не мигайте)
3) Jest выполняет прокрутку произвольного количества строк, которое иногда покрывает все строки console.log, иногда некоторые, а иногда и все.
4) Jest запускает следующий тест (строки console.log из предыдущего теста исчезают).

шутка v18.1.0

Поскольку я не могу выделить это в простом тесте, я предполагаю, что это как-то связано с запуском более сложного асинхронного теста.

У меня такая же проблема, интересно, не перезаписывает ли он другой вывод. Иногда я вижу что-то вроде этого:

image

Это как если бы один процесс выдал ошибку (неудачные типы опор), но это просто записывается прямо в журналы вывода теста.

Более:

image

И иногда, если я Ctrl + c во время выполнения тестов, я увижу журналы консоли, которые я не увижу, если позволю тестам закончиться.

Версии
Шутка: 17.0.1
Узел: 6.6.0
NPM: 3.10.3
macOS: 10.12.2
Терминал: 2.7.1 (а также в iTerm2 3.0.13)
Скрипт (в package.json ): jest /src/main/js --watch или jest /src/main/js --coverage или jest --watch --onlyChanged имеют одинаковое поведение.

@davidgilbertson это происходит на v18.1?

Я пробовал 18.1.0 и это кажется еще более ошибочным. И я до сих пор вижу такие вещи:

image

Я не могу выбрать какой-либо конкретный шаблон, но некоторые вещи, которые уже произошли (у меня есть console.warn('----------------') в одном из моих компонентов).

  • Если при запуске тестов я прокручиваю немного снизу вверх, я вижу журнал. Если я прокручиваю окно терминала во время прокрутки тестов (чтобы он начинал автоматическую прокрутку), тогда, когда тест завершен, я прокручиваю обратно вверх, и строка console.warn исчезает (предположительно перезаписывается).
  • Если я запускаю тесты и сразу нажимаю ctrl + c , я вижу журналы консоли. Но если я сделаю то же самое и не перебью, эти журналы консоли не будут видны.
  • Когда я запускаю jest /src/main/js --watch один раз, а затем нажимаю a чтобы запустить его снова, он собирает множество устаревших тестов в каталоге src/main/assets/legacy - не совпадая с глобусом.
  • То же, что и выше, если я просто запустил jest --watch (все мои тесты заканчиваются на .test.js или .test.jsx ). Таким образом, нажатие «а» в режиме просмотра, кажется, ведет к поиску повсюду, включая старый тест на жасмин под названием src/test/js/spec/categoryselector/spec.js . Нажатие Enter кажется, делает то, что я ожидал.

Может быть, все ошибки, вызванные отсутствием реквизита, вызывают эту проблему? Я должен сохранить ctrl+c в выводе, чтобы попытаться отловить эти ошибки, прежде чем они будут перезаписаны.

У меня тоже не работает (шутка 19.0.1, узел 5.12). Интересно, что он работает над другим проектом с такой же настройкой. Не знаю, как отлаживать тесты Jest, поэтому я думаю, что возможность видеть некоторые сообщения консоли было бы очень важно.

Вы пробовали использовать флаг шутки --runInBand чтобы увидеть, решает ли это проблему путем последовательного выполнения тестов? Кто-то сказал мне об этом, но у меня не было возможности проверить это.

Флаг bail предотвращает печать журналов консоли.

Я постараюсь. Немного обескураживает то, что в одном проекте некоторые операторы журнала консоли выводятся на консоль, а некоторые нет. К сожалению, те, которые я пытался добавить, когда тестовый пример не работает, не выводятся (я пытался добавить везде в тестовом примере, в тестируемом модуле и т. Д., Но безрезультатно). Так что я на самом деле не думаю, что это может быть связано с флагом, поскольку поведение не является лаконичным. Это родной проект с реакцией, кстати, со стандартным макетом.

Кажется, все это не помогает. Флаг --bail просто останавливает запуск других тестов (в моем случае вызывающий нарушение все равно последний), а --runInBands, похоже, не имеет заметной разницы. Jest действительно запускает обновленные файлы, кстати, поэтому, если я вставлю оператор console.log, трассировка стека ошибок покажет ошибку, исходящую из обновленного номера строки. Просто консольного лога не бывает. Поскольку отлаживать эти тесты в браузере сложно / невозможно (пожалуйста, поправьте меня, если это не так), console.log абсолютно необходима для исправления некоторых проблем в тестах.

Похоже, что этот тестовый пример на самом деле не запускался. Произошла ошибка TypeError (доступ к свойству на неопределенном уровне). Что меня ввело в заблуждение, так это то, что я действительно видел трассировку стека на консоли, которая вроде как предполагает, что она выполняется. Так что видеть трассировку, но не видеть сообщение журнала, не совсем понятно :) Кто-нибудь знает, почему это делается таким образом, поэтому, если тест завершается с ошибкой во время выполнения, журналы не выводятся, как кажется? (Для ясности я имею в виду журналы, которые произошли до момента ошибки, я, очевидно, не имею в виду журналы после ошибки :))

В моей среде, я имел verbose: true установите в JEST опции в package.json . Изменение этого параметра на false (или его удаление) устранило проблему для меня. Теперь отображаются все журналы моей консоли.

Это в 18.1.

Если кто-то еще сталкивается с этой проблемой, проверьте недавно добавленные зависимости. Я начал сталкиваться с проблемами после добавления mock-browser в попытке имитировать объекты браузера. По-видимому, он заменяет global своим собственным объектом.

package.json (конфигурация шутки)

"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
Комментируем биты mock-browser ...

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

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

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

console.log отлично работает.

Почему этот вопрос закрыт? Явно не дубликат № 2166

Я добавлю свои 0,02 доллара, потому что я только что столкнулся с этим.

Проблема:

  • Я использую jest --watch --verbose (v19.0.2)
  • Некоторые (но не все!) Операторы console.log не отображаются ни во время тестового запуска, ни в сводке
  • В моем случае, я могу выделить его в _.reduce вызова: все console.log операторов внутри этого блока не показаны, console.log заявления за пределами сокращения блока показаны. Я проверил другими способами (покрытие, результаты тестов), что тело редуктора действительно вызывается. Это странно, поскольку я не делаю ничего async / обещания на основе этой части кода, я не могу понять, почему вызов reduce на что-нибудь повлияет.
  • Если я вызываю шутку с помощью --runInBand , я вижу все инструкции console.log .
  • В отличие от большинства предыдущих отчетов, я использую "testEnvironment": "node" , а не jsdom

Следующие комментарии, похоже, связаны с моей проблемой:

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

Это довольно быстро, но это действительно кажется, что console.logs фактически обращается на экран , а затем переписаны.

Только что подтверждено видео, что console.log на самом деле отрисовывается на экране в течение ~ 0,2 с, прежде чем отрисовывается.

Запуск --watch без --verbose похоже, исправляет это.

Я потратил 10 минут, пытаясь получить единичный репродукционный футляр, но, похоже, не могу этого сделать. Вероятно, это проявляется только в больших (ну,> 1) тестовых наборах.

Вы можете увидеть поведение здесь:

  • Перед console.log
    screen shot 2017-03-29 at 3 38 51 pm

  • console.log - отображается в течение доли секунды (<0,2 с)
    screen shot 2017-03-29 at 3 39 34 pm

  • После того, как console.log закрашен
    screen shot 2017-03-29 at 3 39 47 pm

Эта проблема действительно отстой, тратится много времени на эту проблему, и, похоже, ничего не работает. Я выбрал шутку, потому что думал, что у инженеров Facebook есть приличный набор тестов, а теперь это ...

Вот почему я не люблю Jest. Независимо от того, что вы делаете, они очистят вашу консоль и откажутся отображать какие-либо операторы консоли, а затем каким-то случайным образом они будут появляться, пока у вас не появится ошибка, которую вам нужно исправить, и в этом случае они сделают все возможное, чтобы скрыть каждую log, поэтому вы не можете его исправить.

Почему бы вам просто не ПРЕКРАТИТЬ пытаться скрыть вывод консоли от разработчиков? Если мне нужны тренировочные колеса, я буду использовать Angular 1!

Это довольно агрессивно @halis. Мы делаем это, потому что Jest распараллеливает тесты, и многие тесты могут одновременно регистрироваться в терминале, а это означает, что вывод Jest становится бесполезным. Мы действительно это делали. Если вы используете --verbose , мы фактически ничего не буферизуем и пишем прямо в консоль.

Если это не сработает для вас, возможно, вы можете помочь нам, отправив PR в Jest и улучшив это поведение.

Извините, у меня был действительно плохой день в пятницу, и я был расстроен. Нет причин ссориться с тобой, ты просто пытаешься помочь.

В пятницу я нашел флаг --verbose, который дал мне достаточно информации, чтобы исправить мои проблемы.

Опять же, извините за то, что был таким придурком по этому поводу.

Замечательно. Не позволяйте инструментам JavaScript испортить вам пятницу 😀

есть новости по этому поводу? как показать console.log?

очень интересное поведение, после нескольких ударов головой (скорее, несколько раз) выяснилось, что --verbose действительно является виновником того, что console.log не распечатывается.
Моим лучшим решением было создать другой скрипт в package.json, который не имеет подробного флага, когда я хочу, чтобы какое-то сообщение было распечатано в моей консоли. Был бы очень признателен, если вы ребята исправите это в ближайшее время

Эта проблема действительно очень раздражает, так как затрудняет / делает невозможным отладку тестов с помощью console.log (я знаю ... старая школа, но все же удобная).
Чтобы я использовал параметры --runInBand появились мои операторы журнала.

РЕДАКТИРОВАТЬ: Я почти уверен, что это связано с тем, как результат отображается на экране ... одним из вариантов было бы иметь «фиктивного» репортера, который просто не пытается модернизировать рендеринг. Другой вариант - позволить разработчику выбрать репортера, как это делает мокко.

Это хуже, чем не показывать логи:

Если у меня есть какая-либо форма ошибки в асинхронном тесте, то я не только не вижу сообщений журнала, но и ошибки expect также скрыты, а исключения игнорируются.

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

Нигде не отображается мой тест expect .

`` ''
Тайм-аут - асинхронный обратный вызов не был вызван в течение тайм-аута, указанного jasmine.DEFAULT_TIMEOUT_INTERVAL.

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

`` ''

Ни runInBand ни verbose:false помогают.

У меня банально простой ( babel-jest ) конфиг.

@richburdon для асинхронных тестов с использованием обратного вызова done , в случае сбоя вам необходимо использовать done.fail()

@thymikee спасибо за быстрый ответ. Я не понимаю, что ты имеешь в виду. Можете ли вы изменить мой тест и / или указать мне на документы. Большое спасибо.

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

Я понимаю, что это не идеально, но сейчас это работает именно так. Стоит отметить, что это не проблема, когда тестируемая функция возвращает Promise . Это поведение влияет на несколько проблем, например https://github.com/facebook/jest/issues/2136 или https://github.com/facebook/jest/issues/2059. Если у вас есть идея, как это улучшить, мы хотели бы проанализировать PR и воплотить его в жизнь.

Но это не актуальный вопрос, чтобы его обсуждать, вы можете опубликовать свои идеи в другом месте.

@thymikee , мой пример не был удачным, так как setTimeout имеет проблемы, связанные с обещаниями, которые не имеют ничего общего с шуткой ...

Стоит отметить, что это не проблема, когда тестируемая функция возвращает Promise.

Я этого не вижу:

`` ''
test ('async', (готово) => {
function foo () {
вернуть Promise.resolve (1);
}

foo (). then (value => {
ожидать (значение) .toEqual (2); // Никогда не сообщалось; просто тайм-аут.
Выполнено();
});
});
`` ''

Неочевидно, что код тестирования должен улавливать исключения для вызовов expect (т.е. часть самой среды тестирования). Это кажется довольно запутанным?

Итак, для ясности, я должен обернуть ВСЕ тесты, которые включают любые тестируемые функции, которые возвращают обещания, блоком catch - для перехвата вызовов expect , которые в противном случае: a) тайм-аут; б) не сообщать об ошибке.

Если только я не совершу другую ошибку:

а). Возможно, задокументируйте это (https://facebook.github.io/jest/docs/asynchronous.html#content)?

б). Почему бы не записать ошибку? и / или есть возможность выйти?

У меня такая же проблема с console.log.
Он работал нормально в версии 19, и я смог увидеть результат в консоли.
После обновления до версии 20.0.3 вывод исчезнет.
Я пытался добавить --runInBand или --verbose , но не помогло.

Пожалуйста, обновите nodejs до последней версии. Это известная проблема в узле ~ 7.3.

@thymikee Так они собираются исправить эту проблему? Я все перепробовал под солнцем. По-прежнему нет журналов консоли. Я использую препроцессор машинописного текста и jest. Я использовал ts-jest, и их препроцессор работал. Неужели это как-то связано с препроцессором?

@cpojer @lsentkiewicz Должны ли мы открывать новый выпуск, поскольку это новый выпуск в новой версии?

Как упоминал @cpojer , использование последней версии узла

@marcusjwhelan
У меня работает на v7.10.0

Я все еще вижу, как вывод консоли проглатывается при использовании jest --bail .

@cpojer Не работает на v8.0.0

Не работает на узле 8.0.0

Я чувствую, что это плохая ошибка, если у вас должна быть определенная версия, чтобы она работала. Что делать, если ваша система работает на 6.0 и не работает в 7.0 из-за некоторых изменений nodejs. Разве шутка не должна работать, по крайней мере, на современных версиях Node? минимум 5 лет поддержки? @cpojer @taion

Это ошибка только в узле 7.3. Они объединили плохое изменение и отменили его на 7,4 или 7,5.

Люди говорят мне, что это не работает на узле 8, но у нас есть тест на такое поведение, и он проходит. Если люди хотят создать правильное воспроизведение с помощью Jest 20 и узла 8, создайте для этого проблему.

@cpojer Я не вижу вывода console.log с этой настройкой (macOS):

$ node --version
v7.4.0

Файлы

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

Вывод

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

Единый тест JS:

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

Одиночный тест TS:

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

Такая же проблема с узлом v8.1.2. Я также пробовал node v7.10.0, и это тоже не сработало

Работая над проектом React, я попробовал Jest, потому что Jasmine - это полный квест по тестированию HTTP-вызовов с whatwg-fetch , выполнением Node.js и транспиляцией Babel. Но когда я увидел, что в данный момент с Jest вы не можете печатать на консоли, мне было запрещено использовать эту структуру. Возникла проблема с Node.js 7.10 и Jest 20.0.4.

Наконец, я смог настроить всю среду тестирования с выполнением Jasmine и Node.js, объявив xmlhttprequest в глобальной области видимости и используя nock в качестве поддельного сервера.

Ошибки бывает очень сложно обнаружить и исправить. Но это P0, о котором сообщалось 6 месяцев назад, что помешает кому-либо серьезно рассматривать Jest как среду тестирования для любого проекта React.

У меня была та же проблема, что и на скриншотах @davidgilbertson (результаты теста перезаписывают console.log) на Jest 19.0.2 и Node 7.10.0 при запуске jest --verbose . Что мне помогло: при использовании jest --verbose --runInBand все работало корректно (сначала результат теста, потом весь console.log).

@cpojer @thymikee , пожалуйста, снова

@iffy , не могли бы вы создать отдельный выпуск для вашего репро? Я попытаюсь отсортировать это и посмотреть, что не так.
Кстати, ничего ниже ожидаемого неуспеха никогда не будет вызвано, потому что ожидайте бросков.

@thymikee готово (хотя я уже перешел на мокко, так что не беспокойтесь о сортировке)

У меня тоже была эта проблема, и даже после того, как я прочитал всю эту ветку и попробовал все, я не могу исправить проблему. Мой тест очень прост, потому что я только что реализовал jest в своем приложении, и даже в этом случае console.log не отображается.

Затем я попытался использовать winston для входа в выходной файл, и это сработало. Затем я попытался использовать winston для входа в консоль, и, угадайте, это сработало!

Так что я предлагаю вам сделать то же самое. Проверьте мой logger.js файл:

'use strict';

const winston = require('winston');

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

let config = {
  colors: customColors,

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

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

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

module.exports = logger;

В файлах тестов просто используйте:

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

Winston работает, потому что он использует process.stdout.write который обходит эту ошибку в Jest. В итоге я создал свой собственный console.log, используя модуль узла util .

@eranimo @Daymannovaes посмотрите на ошибку # 3853

В этом комментарии говорится, что он работает в 8.1.2, но я попробовал это, и у меня ничего не получилось. Я уже перешел на мокко, потому что это была довольно серьезная ошибка.

Будет ли эта ошибка исправлена ​​в следующем выпуске? Кроме того, где мне найти, когда это будет?

Я не могу перейти на последнюю версию узла (не вариант), так что это не решение. Я мог бы сделать свой собственный логгер, с которым я могу возиться. Я подумываю о преобразовании в мокко, но это зависит от того, как пройдет мой эксперимент с использованием регистратора.

Пожалуйста, исправьте как можно скорее, журналы консоли очень полезны для написания моих тестов.

Я временно понизил версию до 19.0.2, и она работает.

У меня была такая же проблема, и я просто протестировал ее с последней версией node. Теперь это работает. : 100:

Он также работает у меня после перехода с Node.js v7.10 на v8.1.

исправлено для меня при обновлении узла с 7.4.0 -> 8.2.1

Получение этого на узле v8.4.0 и Jest 21.0.0-beta.1.

При запуске только одного тестового примера с test.only вывод console.log не отображается.

Но если я удалю --testPathPattern file и запускаю все тесты, результат появится.

Кроме того, если я добавлю await Promise.delay(100) качестве последнего шага в тесте, появится результат.

извините за этот комментарий, но это их способ получить Jest в console.log в реальном времени, а не после того, как тест прошел или не прошел. в моем тесте используется цикл while. Я пытался получить значения, зарегистрированные во время выполнения цикла?

@nharrisanalyst использует --verbose

спасибо за ответ, но я использую этот флаг, и он используется только console.log () после того, как тест прошел или не прошел. поэтому, если мой цикл while застревает, я не могу отлаживать его с помощью console.log при тестировании, потому что тест не проходит или не проходит, он просто застревает в цикле.

Кажется, что шутка съедает любую консоль, которую я делаю в setupFiles , setupTestFrameworkScriptFile или beforeAll , что делает невозможным создание сценариев настройки тестирования, которые запрашивают ввод пользователя и проверяют команду. строчные флаги. Бывает с "verbose": true или без него

Делюсь своими наблюдениями о том, что console.log () не отображается при запуске тестов с Jest.

Предварительным условием для этого является запуск Jest с флагом --verbose .

Если вы запускаете тесты с несколькими тестовыми файлами , вывод console.log () не отображается (большую часть времени).
Если Jest запускает тесты только из

Вы можете решить эту проблему следующим образом:

  • Запускайте Jest-тесты только из 1 файла. Ага ... совсем нереально, так что смотрите следующий вариант.
  • Используйте флаг --maxWorkers=1 . Почему-то у меня это хорошо работает. Я предполагаю (*) ... Jest выполняется в одном процессе, и нет необходимости буферизовать стандартный вывод каждого процесса, чтобы передать их обратно в основной процесс.

Если мое предположение (*) является ожидаемым поведением, я предлагаю обновить документацию, чтобы четко указать на это, чтобы разработчики не тратили время на попытки выяснить, «почему мой console.log () не отображается ... иногда».

Хорошо. Так что это все еще проблема для некоторых людей, включая меня сегодня. Я предполагаю, что это будет продолжаться.

Судя по моему тестированию, Jest завершает процесс до вывода журналов, что означает, что журналы проглатываются.

Для меня я установил verbose: true и bail: false в своей конфигурации jest. Jest будет продолжаться до тех пор, пока не будут запущены все тесты, и выведет все ошибки и журналы. Это благоприятно. Я также запустил --runInBand , который делает то же самое, что и установка --maxWorkers=1 .

Самым большим подспорьем было bail: false потому что это позволяло запускать все тесты до завершения. Он по-прежнему завершился с кодом 1 но я снова вижу все журналы.

Запуск Jest v19.0.2 с узлом v8.1.4.

Запуск --verbose --testPathPattern=<path/to/file> привел к печати журналов. В противном случае его проглотят.

Может ли кто-нибудь предоставить небольшое воспроизведение, которое не работает на jest 21.2.0 и текущих узлах (например, 4.8.4, 6.11.4 или 8.7.0)?

Нет необходимости настраивать verbose или дополнительные конфиги jest, и проблема просто исчезла, когда я обновил свою версию узла с 7.4.0 до 8.0.0 . Это мои наблюдения.

Использование [email protected]

Это ТАК расстраивает! У меня есть последние версии всего, и Jest по-прежнему обрезает вывод console.log в, казалось бы, случайных местах. Это очень затрудняет отладку неудачных тестов.

Я только что нашел ответ на это! Если вы отключите подробный режим, появится весь вывод console.log! Я думаю, что когда вывод Jest является многословным, он записывает его поверх вывода из последних нескольких console.logs.

У вас есть какой-нибудь фрагмент кода, который постоянно это воспроизводит? Может помочь нам устранить основную несогласованность, вызывающую проблему.

Я использовал expect(<value>).toEqual("someImpossibleValue") с bail: false чтобы обойти это, когда просто пытался исправить что-то сломанное. Определенно не идеально, но быстро и грязно ...

Может быть, вы могли бы ввести функцию accept (), которая похожа на expect (), но не дает сбоя.

работает v 22.0.4 без console.log .... добавьте это к одной из многих других причин, по которым я не рекомендую шутить

@mvolkmann благодарит за подсказку о подробном режиме. Если в шутку по умолчанию используется режим без подробностей, возможно, стоит подумать об изменении. Мне не кажется интуитивно понятным, что console.logs, который вы помещаете в свой код, просто не отображаются. Это самое первое и самое простое, что делают, когда тест не проходит.

(здесь узел v9.3.0 и jest v20.0.4)

jest ^21.2.1 и node 8.9.4

Jest по-прежнему иногда не выводит журналы консоли, опция --verbose не решает проблему для меня. Я не понимаю, почему этот выпуск закрыт.

@fega, так как никто не предоставил футляр для воспроизведения, мы можем потянуть и протестировать.

$ jest --verbose

эта команда покажет все журналы консоли

@odykyi у меня не работает. шутка 22.1.0 и v8.9.4

странное поведение. Если я установил для verbose значение false мои операторы console.log были напечатаны.

на [email protected] , [email protected] и используя --forceExit , я не вижу вывода console.log из моего протестированного кода, если я явно не установил verbose в false или удалите флаг --forceExit (который я использую временно).

на [email protected] , [email protected] и с использованием --forceExit я не вижу вывода console.log из моего протестированного кода, если я явно не установил для подробного вывода значение false или не удалил флаг --forceExit (который пользуюсь временно).

Наблюдаем точно такое же поведение, как указано выше. [email protected] , [email protected].

console.logging до вызова done() , но вывод не отображается с --forceExit . Когда --forceExit удаляется, вывод console.log отображается в конце.

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

Так разве здесь нет очевидного решения перед принудительным выходом из flush, который есть внутри выходного буфера?

У нас есть тестовый пример: https://github.com/facebook/jest/blob/497be7627ef851c947da830d4a8e21046f847a78/integration-tests/__tests__/console_log_output_when_run_in_band.test.js#L24 Это как-то неисправно?

Может ли кто-нибудь создать репо репродукции, на которое мы сможем взглянуть?

Быстрое добавление: jest --no-cache похоже, также означает, что console.logs не отображается.

С Node 9.7.1 и jest 22.4.2 с babel 7 с использованием verbose, похоже, отлично работает для отображения журналов консоли из тестов:

package.json

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

Прошло какое-то время с тех пор, как это не потребовало вмешательства пользователя, но, похоже, решение было последовательным.

Эта проблема также беспокоила нас в течение некоторого времени, сначала вывод был обрезан случайным образом, теперь вывод полностью игнорируется. Для воспроизведения клонируйте ветку dev / dexie-search-index этого репо:
[email protected] : WorldBrain / Memex.git

Добавьте эту строку где-нибудь в insertTestData () в src / search / index.test.ts:
console.log('!?!?!?!!?!?!!?'); expect(1).toBe(2)

Протестировано на Node.js версий 6.11 и 8.10. Пожалуйста, решите это как можно скорее, так как это делает кодирование ооочень медленнее :(

@frankred, спасибо. Я установил verbose: "false" и он работает.

Вчера наткнулся на эту проблему https://github.com/evanw/node-source-map-support/issues/207, и она показалась ужасно похожей на эту проблему здесь.

Причина, по которой это проблематично, заключается в том, что запись в process.stdout в Node.js иногда бывает асинхронной и может происходить за несколько тиков цикла событий Node.js. Однако вызов process.exit () заставляет процесс завершиться до того, как будут выполнены эти дополнительные записи в стандартный вывод.

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

Я не проверял код, но если process.exit() используется с --forceExit , это объясняет, почему вывод журнала пропадает.

Просто добавил решение, которое сработало для меня в этой связанной проблеме: https://github.com/facebook/jest/issues/3853#issuecomment -375183943

@ledbit Это не сработало для меня. Ух ты, проблема, которая длилась полтора года и до сих пор не решена.

Это правда, но разработчикам по-прежнему нечего делать.

Я обнаружил эту проблему чаще всего во вложенном асинхронном вызове в примере async. Я не совсем уверен, что так с кем-то еще, но демонстрация использования console.log, несомненно, поможет решить эту проблему.

Это, безусловно, происходит со мной. Что вам нужно от меня, чтобы вы могли это исправить?

22 марта 2018 г. в 8:32 Деннис Браун [email protected] написал:

Это правда, но разработчикам по-прежнему нечего делать.

Я обнаружил эту проблему чаще всего во вложенном асинхронном вызове в примере async. Я не совсем уверен, что так с кем-то еще, но демонстрация использования console.log, несомненно, поможет решить эту проблему.

-
Вы получили это, потому что прокомментировали.
Ответьте на это электронное письмо напрямую, просмотрите его на GitHub https://github.com/facebook/jest/issues/2441#issuecomment-375349444 или отключите поток https://github.com/notifications/unsubscribe-auth/ADrayIO4NBB2dZM1XL8ZQO32W9SUngu8YQ .

А еще лучше дерзайте! Вот мое репо. https://github.com/RALifeCoach/handandfootserver.git

Запустите jest из npm или запустите из командной строки. Вы увидите, что существует очень много console.logs, но большинство из них скрыто.

Там - у команды разработчиков есть все необходимое. Пожалуйста, исправьте эту проблему.

22 марта 2018 г. в 8:36 Кристофер Олифант [email protected] написал:

Это, безусловно, происходит со мной. Что вам нужно от меня, чтобы вы могли это исправить?

22 марта 2018 г. в 8:32 Деннис Браун < [email protected] [email protected] > написал:

Это правда, но разработчикам по-прежнему нечего делать.

Я обнаружил эту проблему чаще всего во вложенном асинхронном вызове в примере async. Я не совсем уверен, что так с кем-то еще, но демонстрация использования console.log, несомненно, поможет решить эту проблему.

-
Вы получили это, потому что прокомментировали.
Ответьте на это электронное письмо напрямую, просмотрите его на GitHub https://github.com/facebook/jest/issues/2441#issuecomment-375349444 или отключите поток https://github.com/notifications/unsubscribe-auth/ADrayIO4NBB2dZM1XL8ZQO32W9SUngu8YQ .

@RALifeCoach сейчас смотрит на ваше репо, там довольно много журналов. Не могли бы вы указать, какого именно журнала вам не хватает?

Запустить его. Вы увидите какой-то вывод, но многое будет перезаписано.

В субботу, 14 апреля 2018 г., 3:10 Симен Бекхус [email protected]
написал:

@RALifeCoach https://github.com/RALifeCoach сейчас смотрит ваше репо,
там довольно много журналов. Не забывайте указывать, какой вход в систему
в частности, что вам не хватает?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/facebook/jest/issues/2441#issuecomment-381318608 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/ADrayHQCc8C0NmMmrtE7mEo2jN999CChks5tocsKgaJpZM4LVbUv
.

Я не уверен, что вы имеете в виду под перезаписью. Очищается ли что-то, выводимое на консоль?

Если с помощью console.log написано шесть строк, на короткое время появятся 6, а затем
сводка теста перекрывает некоторые из 6 строк.

В сб, 14 апреля 2018 г., 8:58 Симен Бекхус [email protected]
написал:

Я не уверен, что вы имеете в виду под перезаписью. Что-то выводится на
консоль тогда очищалась?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/facebook/jest/issues/2441#issuecomment-381339074 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/ADrayF0P5SqpHjaAAYcPaIAF7ubSMVRTks5tohyIgaJpZM4LVbUv
.

Я также испытываю то, что описывает @RALifeCoach . Я увижу, как мой вывод журнала мигает на экране, когда тесты запускаются, а затем, когда я прокручиваю вверх, этого вывода больше нет.

Похоже, это все еще проблема, даже на узле 8.11.1. Может быть, нам стоит зарегистрировать новую ошибку и вернуться к ней?

По-прежнему есть та же проблема в узле v8.9.0.

Я могу подтвердить комментарий @RALifeCoach о том, что вывод журнала «перезаписывается» - я наконец-то получил журналы для отображения, пометив каждый из них определенной строкой символов (например, @@@ ) и запустив:

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

Это ужасный взлом (вы теряете всю окраску консоли, но вы все равно видите сбои тестов и окончательную сводку теста), но это единственное, что до сих пор работало. Все остальное я пробовал в комментариях выше. Обратите внимание, что для этого решения необходим аргумент --verbose (и он неявно комбинируется с --watch через react-scripts ).

[Использование react-scripts разветвлено для использования последней версии Jest v23.0.0, node v8.11.2]

Помогает установка "verbose": true в package.json. Журналы отображаются в нижней части вывода.

Человек за закрытый вопрос. Я до сих пор наблюдаю, как люди жалуются на это, поскольку он был создан 2 года назад.

Я думаю, что в Jest есть какой-то код, который подшучивает над нами и "похищает" console.log (),
превращая это в запретную игру, что-то вроде ...

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

Как ни странно, средство для сброса console.log - см. Https://stackoverflow.com/questions/7089443/restoring-console-log
- удалить console.log

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

... и вдруг - Вуаля! - как Феникс из пламени - console.log() снова работает в Jest ...!
Jest даже распечатывает "console.log (информация о местоположении)" перед тем, как записать ваше сообщение ...

>

console.log __tests __ \ libarray-helpers.test.js: 35
Теперь вы меня слышите, Шуты ...?

Кроме того, в последнее время я использовал изоморфный "logatim" https://www.npmjs.com/package/logatim вместо console.log (), и он
кажется невосприимчивым к попыткам угона Jest ... (возможно, он сбрасывает console.log ...)

Вы даже можете превентивно "захватить" console.log за logatim
чтобы зарегистрировать сообщение уровня "информация" зеленым цветом ...

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

(Пожалуйста, не интерпретируйте мою шутливость как воинственность ... какая радость в названии прекрасного продукта Шуткой, если вы не можете пошутить по этому поводу, немного пошутить ...)

Прежде чем сеять ненависть,

У меня была эта проблема «перезаписи» (Windows 10, терминал VS Code, проект node.js), а затем, когда я возился с ней, ошибка перестала происходить. Я думал, что это перестало происходить, потому что я перестал использовать --watch или потому что я добавил параметр "verbose": false , но отмена этих изменений не вернула ошибку.

Я должен спросить, не связывает ли Jest намеренно вывод журнала с тестом, который его произвел? Некоторое время весь вывод на консоль был ниже результатов всех тестов, но теперь он отображается выше всех результатов тестов. Так случайно.

Флаг --watchAll заблокировал это. теперь это работает для меня

После нескольких месяцев использования jest это случилось со мной совершенно неожиданно с узлом 8.9. Одна минута console.log выводила нормально, в следующую просто перестала работать. Я попал в эту ветку и попробовал несколько вещей. Отсутствие использования --watch устранило проблему, но затем мне приходилось каждый раз повторно запускать свою тестовую команду. Использование --watch --verbose false устранило проблему и автоматически запустило мои тесты.

Обнаружив здесь ту же проблему, спасибо за временное исправление @bkempner

Могу подтвердить, что это проблема как в 22.4.4, так и в 23.4.1 (актуально на момент этого комментария). Я использую следующие флаги:

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

Другая проблема по той же теме предлагала добавить параметр --json , который какое-то время работал ... Возможно, с тех пор некоторые зависимости изменились, но вывод STDOUT и STDERR всегда подавляется. Ближе всего к тому, что работало, я использовал --watch ; иногда какой-то вывод прикреплялся к концу без перезаписи.

Я обнаружил, что --silent по умолчанию истинно, при установке значения false выводится console.log: jest --silent=false

Кажется, что об этом еще тонна сообщений, что-то явно все еще не работает. Это было закрыто как ошибка # 2166, которая сейчас закрыта, но это все еще сохраняется.

@thymikee Можем ли мы снова открыть эту проблему?

Я открываю это снова, так как проблема частично вернулась, и нам нужно ее исправить.

В версии 23 проблема проявляется в режиме просмотра, поскольку мы изменили принцип его работы, чтобы почти всегда запускать тесты параллельно, поэтому TTY не блокируется, и можно легко отменить длительные тесты: https: // github. ком / фейсбук / шутка / тянуть / 6647.
Единственный случай, когда мы не создаем воркеров в режиме просмотра, - это когда у нас есть ровно 1 тест для запуска, и он относительно быстрый (выполняется менее 1 с) - в этом случае мы все равно должны видеть, как console.log появляется, как всегда.

В моем случае выполнение всех тестов в режиме часов делает правильно регистрируется. Если я использую режим шаблона для фильтрации только одного тестового класса, то ведение журнала усекается.

Согласно комментарию @davidgilbertson (https://github.com/facebook/jest/issues/2441#issuecomment-286248619) удаление verbose: true в моем package.json и удаление --verbose из моего Флаги командной строки позволяют мне просматривать журналы консоли, которые в противном случае были скрыты. Это довольно сбивает с толку.

У меня есть verbose: true в моем package.json, и я обнаружил, что операторы console.log иногда присутствуют, а иногда нет (если у меня есть примерно 10 сгруппированных вместе, они, кажется, появляются, но не только для одного) - я думаю, это может быть проблема с асинхронностью

У меня тоже иногда возникает эта проблема, я включаю runInBand (https://jestjs.io/docs/en/cli.html#runinband), и это исправляет.

@ndelangen , это любопытно - интересно, может быть, это проблема с асинхронностью. Я думал, Jest собирает все console.logs и затем распечатывает их, не так ли?

Проблема повторяется сейчас, хотя я не использую verbose .

--runInBand мне не помогает. Единственный надежный обходной путь на данный момент - это просто регистрировать что-то несколько раз, чтобы часть вывода не была перезаписана шуткой.

Я провел некоторый анализ, добавил несколько комментариев и смог создать здесь частичный патч:

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

редактировать:

репо, содержащее код для легкого воспроизведения, доступно здесь: https://github.com/spion/jest-logging-repro

анализ вывода здесь: https://gist.github.com/spion/bbb34c5abc1230a37ad5f4f01336b8df

Патч частичный, потому что

  • многие интеграционные тесты теперь не работают из-за необходимых изменений в выводе
  • иногда (к сожалению) вывод журнала появляется после последнего обновления статуса - вероятно, причина в том, что потоки дочерних процессов сбрасываются после того, как дочерний процесс отправляет сообщение об успешном завершении родительскому процессу.

@philraj такая же проблема для меня .. мне нужно войти несколько раз, чтобы надежно увидеть предполагаемое сообщение журнала

как это не является серьезной проблемой и не решается как можно скорее? как эта проблема открыта с 2016 года ??

Обновление: с этим патчем у меня осталось только 8 неудачных тестов:

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

В основном они не ожидают FORCE_COLORS в process.env, hg scm и packages/jest-runner/src/__tests__/test_runner.test.js не полностью имитируя потоки (поэтому для них нет методов конвейера.

С такой скоростью я смогу отправить PR, который исправляет на следующей неделе ... при условии, что я найду исправление для вывода журнала, появляющегося после завершения всего отчета.

Как сказал @bkempner , использование --watch --verbose false устраняет проблему.

Вывод консоли в --watch , перезаписанный шутливым перемещением курсора, согласуется с тем, что я вижу. Наличие / отсутствие --verbose , --maxWorkers 1 , --runInBand не приводит к успеху.

Мой текущий обходной путь - jest --watch | cat . Я теряю весь цвет и остаюсь в верхней части окна, но получаю вывод консоли.

Или TERM=dumb jest --watch . Я теряю возможность оставаться в верхней части окна, но получаю цвет и вывод на консоль.

У меня такая же проблема.

Что сработало для меня, так это использовать console.debug

TERM=dumb исправляет это и для меня

FWIW, TERM = dumb также исправляет это для меня

отключение verbose в конфигурации шутки у меня сработало 0_o \

Добавление --verbose false в "тестовый" скрипт package.json решило проблему для меня. Я бы никогда не нашел этого без этой ветки.

например

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

Странно, как некоторые из последних консолей исчезают, но не все, исправлено с помощью --verbose false в моей команде часов.

Отлично работает, когда вы запускаете без --watch поэтому это связано с флагом наблюдения, который делает это.

Что так иронично, так это то, что при работе console.log он более подробный!

Я начал замечать эту проблему с подробным описанием в Jest 23.6, я откатился до 23.5 и все еще вижу это. Если я запустил --clearCache это исправит подробные сведения на некоторое время, пока снова не произойдет сбой. Я не понимаю, что является триггером, например, множество сбоев журнала или что-то в этом роде. Как только это происходит, похоже, что Jest повреждает кеш. Я пробую --verbose false и смотрю, мешает ли это продвижению вперед.

Спасибо @jamespolanco. Использование --clearCache устранило для меня проблему (на данный момент). Я собираюсь запустить свои тесты, используя параметр --no-cache и посмотрю, предотвратит ли это повторение проблемы в будущем.

РЕДАКТИРОВАТЬ: я должен был упомянуть, что моя проблема заключалась в том, что были распечатаны только некоторые из моих сообщений console.log . Я использовал 5 строк console.log в одном тесте, и были напечатаны только первые 3 строки. Использование --clearCache устранило эту проблему для меня. Может быть, есть другая проблема, когда не появляются console.log s?

У меня тоже есть эта проблема. Я пробовал использовать console.log, console.debug и console.error. Я также пробовал использовать флаг --no-cache. Во всех случаях мой консольный оператор полностью игнорируется.

У меня такая же проблема в режиме часов. Версия 23.6.0

Я даже записал это, если кто хочет убедиться сам:
asciicast

как и другие - стирается только при запуске с --watch . Пробовал --verbose false и это не помогло.

У меня такая же проблема.

Я тоже испытываю это при использовании подробных сообщений или в режиме просмотра

Хотите верьте, хотите нет, но иногда я выдаю ошибку в журнале. Также выполнение node --inspect node_modules/.bin/jest --runInBand mypath/to/my.test.js показывает реальные выходы console.log в моем случае.

Узел v9.11.1
Шутка: v23.6.0

Конфигурация Jest в package.json :

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

Я подтверждаю, что эта проблема носит подробный характер. Проблема в том, что подсчет количества строк сбивается, когда включен подробный анализ.

Если кто-нибудь может указать мне место, где печатается сообщение, я могу нанести удар.

Вы можете смягчить проблему с помощью jest-watch-toggle-config на данный момент.

Настройте это так:

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

При запуске теста нажмите v чтобы включить подробный анализ, а затем снова v чтобы отключить его.

После этого, если вы отключите подробный отчет, вы сможете видеть все журналы.

--verbose=false исправил проблему при тестировании фермента неглубоко . Однако console.logs работала без исправления для монтирования фермента .

Это предполагает различие между тем, как ошибки регистрируются модулем react-test-renderer, и тем, как они регистрируются встроенным модулем визуализации реакции (поскольку фермент вообще не вмешивается в функции консоли).

К вашему сведению, этот PR решает проблему для меня - https://github.com/facebook/jest/pull/6871

Он еще не готов, возможно, потребуется изменить подход, но он отображает все зарегистрированные данные в подробном режиме.

Еще не обновился (запущен jest 22.4.2), но в режиме просмотра мои журналы не отображались. Запуск с --runInBand исправил это в режиме просмотра.

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

Я тоже не обновлялся (Jest 23.6.0), и запуск с "jest --watch --verbose = false" исправляет это и для меня.

Хотелось бы, чтобы люди, у которых возникли проблемы, протестировали упомянутый выше PR. Он доступен в jest@beta (прямо сейчас 24.0.0-alpha.9 )

Итак, пряжа добавляет jest @ beta?

онс. 19. des. 2018 кл. 16:46 скрев Симен Бекхус [email protected] :

Хотелось бы, чтобы люди, у которых возникли проблемы, протестировали упомянутый выше PR. Это
доступно в jest @ beta (24.0.0-alpha.9 прямо сейчас)

-
Вы получаете это, потому что подписаны на эту беседу.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/facebook/jest/issues/2441#issuecomment-448641697 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAM5P7ijQjSbWB0-zzDCfC9Uggyk5RGoks5u6l9EgaJpZM4LVbUv
.

>


Тарьей Хусе
Мобильный: 920 63 413

@tarjei , да:

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

У меня это работает. 🎉

Это действительно глупо, но на всякий случай я работаю над новым (для меня) проектом - шутка была запущена с параметром --silent который отключает вывод. Удалено, и теперь я вижу логи 🤦‍♂️

Обратите внимание, когда включена подробная информация (я переключаю ее с помощью jest-watch-toggle-config ), часть журнала консоли блокируется в бета-версии.

--verbose = ложь

Это сработало для меня.

Я заметил, что некоторые console.log() в моих тестах работали, а другие - нет (узел 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
*/

Происходит что-то очень странное, с тестами async где первый console.log в асинхронном тесте не регистрируется, а также тот, который после await не регистрируется.

Добавьте еще console.log в этот тест async и вы начнете замечать еще более странное поведение, например, некоторые журналы после того, как await внезапно заработает 🤷‍♀️ 🤷‍♂️

Итак, что @philwhln написал выше два года назад

Поскольку я не могу выделить это в простом тесте, я предполагаю, что это как-то связано с запуском более сложного асинхронного теста.

Кажется, в этом есть доля правды.

--verbose = ложь

В этом случае у меня тоже сработало.

@DanweDE, можете ли вы проверить, версия yarn add jest<strong i="6">@beta</strong> --dev проблему за вас, даже если для подробного набора задано значение true ?

Добавление --verbose false устранило проблему. Это кажется немного неинтуитивным :)

Это исправлено? Я все еще не вижу console.logs по запросу "jest": "23.6.0"

@iDVB Если вы прочитаете @spion

Также все, кто приходит сюда, чтобы сказать --verbose false или --verbose true или любая комбинация флагов или версий Node или Jest, исправили свою проблему, попробуйте бета-версию и сообщите, решит ли она вашу проблему без обходного пути.

логи консоли в тестируемых мной классах действительно появляются

@philraj мы перешли на бета-версию "24.0.0-alpha.9" на @leaplabs, и она работает безупречно. В том смысле, что я не видел, чтобы журналы исчезли после обновления.

Также могу подтвердить, работает с 24.0.0-alpha.9 без каких-либо аргументов командной строки.

Я относительно новичок в React и Jest. Мне не удалось получить согласованные журналы, используя значения по умолчанию из приложения create-response-app. Я катапультировался, и теперь логи работают нормально. Не думаю, что катапультирование изменило версию Jest. Возможно, это просто изменило одну из настроек работы Jest. Это с 23.6.0 .

При использовании 24.0.0-alpha.16 я не вижу никаких журналов консоли, пока не добавлю verbose=false .

Я также получаю довольно противоречивые результаты на [email protected]. Если я запускаю в режиме просмотра все (a), то я могу видеть вывод консоли, но не, если я запускаю соответствующие изменения, режим просмотра (o)?

--verbose=false исправил это и для меня 🎉

Я использую 24.1.0 и он работает даже без дополнительной опции. Однако он не выводит никаких операторов console.log в тестовом файле, если тестовый файл содержит, например. ссылка на класс, который не импортируется. Например

image

Это ошибка ts-jest и здесь не актуальна

Да, но при возникновении этой ошибки вывод журнала консоли не отображается. Это все еще актуально для ts-jest ? Я не очень хорошо разбираюсь в том, за что отвечает каждая библиотека вокруг jest.

IDK, как работает ts-jest , но если он не запускает никаких тестов на ошибки типа, это объясняет, почему они отсутствуют - код никогда не запускается

Я все еще пытаюсь заставить console.log работать здесь. Время от времени я получаю журналы, но, похоже, нет никаких заметных закономерностей для успеха.

Я использую Jest 24.7.1 а также пробовал 24.7.1 и 24.2.0-alpha.0 .

Установка verbose=false и verbose=true не смогла исправить ситуацию.

Я также пробовал использовать node v10.8.0 и v6.17.1 , также без исправлений.

Здесь чего-то не хватает?

@mulholio , вы на 100% уверены, что используете локально установленную шутку? В прошлом я сообщал о проблемах, которые возникали только потому, что у меня была старая глобальная версия пакета, которая работала вместо локально установленной.

Да, глобальные версии Jest не установлены

Я могу подтвердить, что это не было решено. иногда console.log работает, а иногда нет, как меня смутило.
моя среда следующим образом:
шутка 23.6.0
узел v8.13.0
и мой 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"],
}

да, после удаления подробного: правда , вроде нормально

Я тоже вижу эту ошибку, можем ли мы повторно открыть эту проблему?

К вашему сведению: если я использую fit для запуска одного теста, мой console.log s ничего не выводит. Когда я провел весь набор тестов, console.log s работали нормально.

Столкнувшись с той же проблемой, некоторые журналы консоли "съедаются". Для тех, у кого есть эта проблема, можете ли вы проверить, кроме клонирования нескольких журналов консоли?

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

Похоже, что буфер для оператора [PASS] записывает последние 2 строки журнала консоли (я вижу часть номера строки журнала консоли в конце оператора Pass)

+1000

звучит очень глупо, но убедитесь, что вы yarn build перед тестами!

По-прежнему нет вывода с --verbose=true или --verbose=false при использовании [email protected] - не уверен, почему это все еще проблема через 3 года после того, как она была первоначально зарегистрирована.

Вы пробовали использовать флаг шутки --runInBand чтобы увидеть, решает ли это проблему путем последовательного выполнения тестов? Кто-то сказал мне об этом, но у меня не было возможности проверить это.

Спасибо, это работает! Но почему бы не установить по умолчанию вывод console.log ..

Для меня это все еще проблема, [email protected]

На самом деле я нашел исправление, последние 2 строки в последнем тестовом примере (каскадирование) переопределяются, поэтому сделайте это своим последним тестовым примером

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

Тем, кто пользуется ts-jest , пришлось отключить диагностику, чтобы увидеть console.logs
jest.config.js

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

Тем, кто пользуется ts-jest , пришлось отключить диагностику, чтобы увидеть console.logs
jest.config.js

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

Этот вариант у нас не сработал. Мы также пробовали установить verbose = false что тоже не помогло.

Наше окружение:

  • Узел 10.16.0
  • шутка 24.8.0
  • ts-jest: 24.0.2
  • машинописный текст 3.5.2
  • @ типы / шутка 24.0.15

Похоже, что буфер для оператора [PASS] записывает последние 2 строки журнала консоли (я вижу часть номера строки журнала консоли в конце оператора Pass)

Мне кажется, что это действительно так ([email protected]). В моей системе строка вывода терминала с [PASS], кажется, мигает некоторым содержимым, прежде чем его очистить.

Также испытываю эту проблему.

Я не могу войти ни с одним из вышеперечисленных решений, но в качестве обходного пути я просто ожидаю, что потерплю неудачу со значением и проверю разницу:

expect(thingIWantToLog).toBe({})

Загляните и в это: похоже, что вывод "PASS: ..." перезаписывает стандартный вывод, поэтому ваш "последний" console.log будет съеден.

Если --verbose=false не работает, вы можете добавить несколько жертвенных символов новой строки ( \n ) в свой последний console.log.

Вы пробовали использовать флаг шутки --runInBand чтобы увидеть, решает ли это проблему путем последовательного выполнения тестов? Кто-то сказал мне об этом, но у меня не было возможности проверить это.

Добавление этого флага помогло решить проблему.
Время от времени он также не отображал выходные данные console.log.
Используя эту команду:
npm test -- --verbose --runInBand -t "My Test Name"

Версии узла и NPM:
node v8.16.0
npm 6.4.1

Это моя работа:

npm install --save-dev sprintf-js

В шутку setupTest.js или где угодно:

import {sprintf} from 'sprintf-js';

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

По-прежнему нет вывода с --verbose=true или --verbose=false при использовании [email protected] - не уверен, почему это все еще проблема через 3 года после того, как она была первоначально зарегистрирована.

Это мой jest.config.js и у меня это сработало.
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,
};

Тогда в package.json меня есть:

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

Затем запустите свой конкретный набор тестов с помощью этой команды:

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

--verbose=false похоже, у меня сработало. Спасибо!

Jest скрыть журналы и предупреждения, когда вы передаете параметр --silent
Попробуйте yarn jest он должен работать

Этот баг так надоедает ... 3 года ...

выключить - тихо
и для тестов ts с использованием решения ts-jest @ mr-madamin, которое у меня работает!

Не использую verbose или silent , пробовал --runInBand , TERM=dumb , выполнял все тесты по сравнению с одним тестовым файлом, и console.log появляется, когда помещается в блоки настройки, но не в блоки it() .

Когда ничего не помогает, вы все равно сможете:

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

Но я чувствую себя пещерным человеком, который раскалывает арахис камнем.

изменить: "jest": "^24.9.0"

Я использую эту команду, и она работает:

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

Вы можете указать свое имя теста после флага -t, чтобы запускать отдельные тесты или группы тестов с одним и тем же описанием () .

Не использую verbose или silent , пробовал --runInBand , TERM=dumb , выполнял все тесты по сравнению с одним тестовым файлом, и console.log появляется, когда помещается в блоки настройки, но не в блоки it() .

Когда ничего не помогает, вы все равно сможете:

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

Но я чувствую себя пещерным человеком, который раскалывает арахис камнем.

изменить: "jest": "^24.9.0"

Я был взволнован тем, что наконец начал использовать шутку на бэкэнде для единообразия. Вместо этого я столкнулся с этой проблемой и сейчас снова переключаюсь на mocha / proxyquire. Вывод console.log отображается (в модулях или тестовых примерах), и после нескольких часов, проведенных с ним, ни один из обходных путей, похоже, не помогает. Меня не интересуют какие-либо обходные пути, связанные с ведением журнала в файлы ...

Протестировано на узле 8/10 LTS с "jest": "^24.9.0",

Ага. Я тоже на грани. Похоже, здесь более популярно закрывать проблему и рекомендовать хаки вместо исправления очевидной проблемы на протяжении более 3 лет.

Здравствуйте самлевин и павеллоз,
Вы пробовали этот вариант?

Я использую эту команду, и она работает:
npm test -- --runInBand -t "My Test Name"

Вы можете указать свое имя теста после флага -t, чтобы запускать отдельные тесты или группы тестов с одним и тем же описанием ().
Не могли бы вы сообщить мне, работает ли это? Как я уже давно им пользуюсь.

Вот снимок экрана с примером кода и вывода.
ПРИМЕЧАНИЕ: если вы не знаете, console.lg печатается поверх всех других отчетов, а не в конце, где вы видите отчет о покрытии кода или резюме ошибки.
Jest test console log

Мои версии Node и NPM:

node v8.16.0
npm 6.4.1

Я был взволнован тем, что наконец начал использовать шутку на бэкэнде для единообразия. Вместо этого я столкнулся с этой проблемой и сейчас снова переключаюсь на mocha / proxyquire. Вывод console.log отображается (в модулях или тестовых примерах), и после нескольких часов, проведенных с ним, ни один из обходных путей, похоже, не помогает. Меня не интересуют какие-либо обходные пути, связанные с ведением журнала в файлы ...

Протестировано на узле 8/10 LTS с "jest": "^24.9.0",

Я тестировал каждое решение в этом потоке.

Просто чтобы проверить, не изменилось ли в этом плане ничего:
image

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

Редактировать

ПРИМЕЧАНИЕ: если вы не знаете, console.lg печатается поверх всех других отчетов, а не в конце, где вы видите отчет о покрытии кода или резюме ошибки.

Я даже не проверял нижнюю часть отчета, но именно туда попал мой журнал. Так что, я думаю, это работает, но не для всех одинаково / одинаково.

image

Спасибо за помощь.

Вопрос в том, насколько это сказывается на производительности, но это в другой раз, логирование важнее.

Вы правы @pavelloz , когда вы запускаете тесты с параметром

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

Поэтому я использую эту опцию только тогда, когда мне нужно отладить проблему в тесте.
В остальное время просто запустите тест в обычном режиме.

Ваше здоровье

const component = мелкий (...)
console.log (component.debug ())

Невероятно, но это еще не исправлено.

@ivandosreisandrade Мне удалось проверить обходной путь флага runInBand но в настоящее время я бы не стал тратить время на добавление дополнительного шага для других разработчиков и вернулся к чему-то, что ведет себя так, как ожидалось из коробки. останется подписанным, чтобы увидеть, не изменится ли что-нибудь в этом отношении

Я перепробовал все в этом потоке, но по-прежнему не вижу вывода console.log. --runInBand для меня проблему не решает. Используя node @ 12 и последнюю версию jest. Отладка с помощью веб-разработчика достаточно сложна, было бы действительно полезно, если бы я мог хотя бы распечатать на экране, чтобы увидеть, почему мой модульный тест не работает.

@ u84six вы пробовали мое решение?
Вот ссылка на мой ответ на пост.
https://github.com/facebook/jest/issues/2441#issuecomment -552368939

Ваше здоровье

@ivandosreisandrade происходит то, что если в коде есть ошибка (например, ссылка на неопределенное значение), он не распечатывается, даже если вызов console.log находится перед ошибкой. Если в тесте все прошло успешно, то я увижу журнал. Такое поведение делает его совершенно бесполезным для отладки.

@ivandosreisandrade как выглядит ваш package.json? Я пытаюсь следить за этим:

npm test - --runInBand -t "Имя моего теста"

Но у меня он настроен так в моем package.json

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

Вы могли подумать, что с флагом --verbose он позволит пройти console.log, но я все еще не могу заставить console.log работать. Так обидно!

@ivandosreisandrade как выглядит ваш package.json? Я пытаюсь следить за этим:

npm test - --runInBand -t "Имя моего теста"

Но у меня он настроен так в моем package.json

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

Вы могли подумать, что с флагом --verbose он позволит пройти console.log, но я все еще не могу заставить console.log работать. Так обидно!

@ u84six это мой packadge.json

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

Ваш testMatch допускает либо .js или .jx или .jsx files, а ваш moduleFileExtensions допускает только .js . Кажется, что-то здесь не так.

Это не имеет отношения к причине: man_shrugging:
Это как раз тот файл, который нужно найти и провести с ними тесты.

Я не уверен, почему проблема закрыта. Итак, вот моя версия узла - 13.12.10, npm -6.14.4
шутка -24.9.0

Вот базовый тест с mock-fs
импортировать mock из mock-fs;
импортировать * как fs из 'fs';
импортный насос от 'помпа';
import * as util из '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', () => {

    });
});

Я не уверен, почему это происходит. Это из-за цикла событий, в котором console.log считается обработанным в nextTick () только после выполнения тестовых спецификаций. Приносим извинения за то, что подняли этот вопрос, но отладка каждого отдельного тестового примера кажется утомительной, а не просто запускать консоль и проверять данные req.

Потому что вы должны вернуть свое обещание filePromisy шутить, чтобы он знал, когда ваш тест завершен - ваша проблема не имеет ничего общего с этим.

Я обошел эту проблему в целях отладки, просто поместив все, что я хотел, во временный оператор expect . Итак, вместо console.log(sketchyVariable) используйте expect(sketchyVariable).toEqual(42) .

Что сработало для меня на Node 8:
Вместо использования console.log используйте встроенный журнал отладки:

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

И начнем шутку с флагом отладчика:

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

Я заметил, что журналы консоли периодически появляются при просмотре одного теста. Иногда я видел все журналы, иногда - ни одного, а иногда я видел некоторые из них, но не все. Каждый раз при запуске теста я видел что-то другое. 😒

--verbose=false исправил это для меня. Я был удивлен этим, потому что я нигде не устанавливаю verbose на true . Оказывается, Jest автоматически установит для него значение true если вы запускаете один тест . 🙃

если запущен только один тестовый файл, по умолчанию будет true.

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

Связанный поток StackOverflow: https://stackoverflow.com/questions/48695717/console-log-statements-output-nothing-at-all-in-jest

jest плохо обрабатывает ведение журнала на нескольких уровнях. должно

  • захватывать и отображать все записанные журналы для одного теста при сбое по умолчанию
  • есть возможность вообще ничего не показывать, и
  • есть возможность отключить захват.

Это оно. на самом деле не сложно.

Я предполагаю, что они собирают журналы консоли, потому что они пытаются получить асинхронный вывод для печати в разумном порядке при запуске тестов. Проблема в том, что если этот код ведения журнала не работает для пользователя, в его среде они в значительной степени закрыты.

Я перестал использовать шутку много лет назад, потому что я не мог надежно получить вывод консоли при отладке тестов, независимо от того, каким предложениям я следовал в этом потоке.

Мораль этой истории такова: не связывайтесь с глобальной консолью. КОГДА-ЛИБО. Если вы хотите предоставить регистратор, который можно включить или выключить, сделайте это. Я воспользуюсь им, если захочу. Но в глобальную консоль вмешиваться не стоит.

Загрузите Outlook для iOS https://aka.ms/o0ukef


От: earonesty [email protected]
Отправлено: среда, 12 августа 2020 г., 12:33:23
Кому: facebook / jest [email protected]
Копия: Крис Граймс [email protected] ; Упомяните упоминание@noreply.github.com
Тема: Re: [facebook / jest] console.log не выводится при запуске тестов (# 2441)

jest плохо обрабатывает ведение журнала на нескольких уровнях. по умолчанию он должен собирать журналы и отображать их при сбое, иметь возможность не отображать вообще и иметь возможность отображать все. Это оно.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/facebook/jest/issues/2441#issuecomment-673011577 или откажитесь от подписки https://github.com/notifications/unsubscribe-auth/AAFCNBK5MQEA6AJHEC52ZWDSALG6C2VWW .

@halis Я использовал Jest время от времени около четырех лет, и это всегда было проблемой. В результате Jest-тесты довольно сложно отлаживать.

Я считаю, что основная задача Jest - быть счастливым, чтобы время от времени нарушать ожидаемое поведение и семантику, если это значительно улучшает опыт тестирования. Такие вещи, как автоматический подъем jest.mock(...) означают, что тесты Jest не являются строго JavaScript (или даже ECMAScript) по своей семантике; аналогично параллелизм означает, что любые встроенные методы, возвращающие пустоту, такие как console.log могут и должны рассматриваться как асинхронные, если это может улучшить производительность.

Это плохо? Ясно, что не обязательно, поскольку Jest чрезвычайно успешен. Но я действительно думаю, что у Jest есть способность время от времени вас удивлять. Я почти уверен, что 90% пользователей Jest понятия не имеют, что их код AST-преобразован, например, для поднятия ложных вызовов.

Я почти уверен, что 90% пользователей Jest понятия не имеют, что их код AST-преобразован, например, для поднятия ложных вызовов.

КАКИЕ

Попробуйте использовать console.debug или console.error

Вы можете использовать --useStderr в моем случае проблема решена, потому что он передает сообщения напрямую

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

Сегодня я снова боролся с этим, и флаг --useStderr исправил это для меня. Спасибо @diomalta!

Я боролся с той же проблемой, журналы не отображались, когда тест не удался.

Мне удалось показать свой console.log , установив verbose: true в моем jest.config

Была ли эта страница полезной?
0 / 5 - 0 рейтинги