@thymikee Есть идеи, почему это происходит?

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

Я могу воспроизвести без Typescript

Могу подтвердить, что Node 7.4 потребляет журналы консоли, но работает на Node 7.5.0, 7.10.0, 8.0.0 и 8.1.2.
Пожалуйста, обновите версию Node. Закрытие

@thymikee А как насчет Node 6, который является текущей версией LTS? (Похоже, я тоже столкнулся с этим, хотя еще недостаточно отладил его. Однако пока я ограничен выпусками LTS, поэтому не могу обновиться).

Протестировано на v6.11.0, по-прежнему показывает console.log s.

Ах, может быть, я столкнулся с какой-то другой проблемой. Спасибо, @thymikee , я еще немного вернусь к отладке.

Я запускал Node 7.3.0 по незнанию (неправильная версия через n), и он не вел журнал. Перешел на 8.1.1 и снова зарегистрировался.

@thymikee - я не понимаю, как это решение? ... Я не могу обновить версию своего узла

Думаю, я немного сбит с толку, как это может считаться ошибкой Node и, по крайней мере, не иметь никакого отношения к самой Jest. Используя Node v7.4.0 с Jest v19.0.2, я вижу ведение журнала консоли из своих тестов. Простое обновление Jest до версии 20.0.4 (без внесения каких-либо изменений в любую другую конфигурацию) приводит к тому, что ведение журнала консоли больше не отображается. Есть что-то, чего мне не хватает?

@thymikee Итак, я обновил версию своего узла и не вижу журналов консоли на узле 8.2.1 Winx64 + Jest 20.0.4. Я должен использовать запасной вариант на данный момент

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

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

@nowherenone , можете ли вы проверить, происходит ли это в последней альфа-версии jest@test ?

@thymikee Только что попробовал с jest@test на узле 8.2.1 , но результат тот же. Операторы console.log всегда проглатываются.

@thymikee Проблема в модуле BufferedConsole, где параметры конструктора консоли не соответствуют ожидаемым.

Я открыл PR, может поможет: https://github.com/facebook/jest/pull/4157

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

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

Не используйте Jest — это мой ответ, если вам интересно. Найдите новую среду тестирования.

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

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

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

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

Я уверен, что мне просто скажут установить более новую версию Node Lmao — какая шутка 😂 😂 😂

@nf071590 не может воспроизвести, работает на repl.it с точно такими же версиями Jest и Node: https://repl.it/KYLc/0

Пожалуйста, придумайте серьезную репродукцию, прежде чем разглагольствовать о сопровождающих проекта.
Ваше здоровье!

Не знаю, что с этим делать. Я буквально вставил ваш пример в файл и запустил Jest, и он работает так, как рекламируется на моем Mac, с последней основной версией Jest, выпущенной минуту назад. Видеть:

Добавление, так как я нахожусь в Windows (узел 8.4, шутка 21.0.0-alpha.2), console.log s _иногда_ скрыты, если вы не используете --verbose , но, кажется, постоянно отображаются с этим. С удовольствием обновлю результаты, используя узел 7 и стабильную шутку, когда у меня будет минутка.

Здесь та же проблема.

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

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

В настоящее время возникает такая же проблема на узле v8.7.0 (npm v5.4.2).

Это все еще проблема

Вы можете предоставить репродукцию?

FWIW, я оказался здесь, потому что у меня была точно такая же проблема. Узел v7.4.0. Обновил мою версию Node, и теперь console.log печатает, как и ожидалось, даже без --verbose . V7.4.0 может быть не единственной версией с этой проблемой, но похоже, что она связана с версией и не является проблемой для некоторых версий Node. Сейчас я использую Node v8.3.0, который, похоже, работает.

Тем не менее, до обновления у меня были те же версии, что и у @nf071590 , и те же проблемы. Я не уверен, почему этого не происходит на repl.it, но это не какая-то странная вещь, происходящая только на его компьютере.

Я могу воспроизвести это с помощью node 8.9.0 и jest 21.2.1, macOS 10.12.6 (16G1036)

@SimenB Я мог бы, но похоже, что эта проблема обсуждалась до смерти здесь и в других местах. Природа шутки с несколькими (дочерними) процессами означает, что она перезапишет console.logs , и без масштабной перезаписи это не изменится. Любой, кто приходит в эту тему и хочет избежать проблемы, когда использование флага --verbose запрещает отладку с помощью console.log , должен использовать флаг --watch . Это предотвратит перезапись дочерних рабочих процессов и позволит вам увидеть подробный вывод с журналами консоли. --watch работает очень быстро и повышает ценность за счет сосредоточения внимания на тестах и ​​коде, которые были изменены, за счет запуска только тех тестов, которые были изменены при сохранении.

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

Я только что обновил версию своего узла с v6 до v9, и один из моих тестовых файлов утешает.

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

Проблема все еще сохраняется с --verbose сочетании с --forceExit — я думаю, причина этого в том, что console.log выводит в stdout , а jest записывает в stderr и когда --forceExit в stdout все еще может быть содержимое, которое не сбрасывается

Я нашел следующее решение (без необходимости --verbose ), чтобы исправить то, что console.log не отображается, и/или console.log буферизуется и не отображается в реальном времени.

команда
jest .... --forceExit --setupTestFrameworkScriptFile ./src/tests/jestShim.js

содержимое jestShim.js

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

Та же проблема - никогда не видеть вывод console.log.

Node 9.80 Jest 22.4.2 Mac OS 10.13.3

Ни один из предложенных здесь обходных путей не сработал для меня.

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

Обходной путь @ledbit сработал для меня
НПМ 5.3.0
шутка 22.4.3

• Mac OS

Я все еще нуждаюсь в репродукции.

--forceExit кажется несколько сломанным, но я не сталкивался с этим, когда не использовал этот флаг

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

Наконец, я получил журналы для отображения, пометив каждый из них определенной строкой символов (например, @@@ ) и запустив:

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

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

Это все еще проблема. Я использую jest v22.4.3 на Node 10.1.0 и вижу только первый оператор console.log моего приложения, все остальные игнорируются. Когда я устанавливаю свою библиотеку журналов для потоковой передачи на стандартный вывод, я вижу некоторые журналы, но они отображаются не в правильном порядке.

Работа Jest как исполнителя тестов заключается в том, чтобы помогать нам отлаживать и исправлять наш код. Без логов этого просто не добиться.

@thymikee, пожалуйста, снова откройте этот вопрос

@thanpolas не стесняйтесь создавать новую проблему с репозиторием, показывающим ошибку, чтобы мы могли ее исследовать :). Кроме того, пожалуйста, используйте Jest 23, так как это последняя версия.

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

Что бы это ни стоило, я видел различия между Терминалом и iTerm2.

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

Вот один пример ошибки, которую мне удалось воспроизвести. Не уверен, что есть несколько источников:

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

yarn install; yarn repro

Настройка: Jest находится в режиме просмотра, с включенным флагом подробных сведений, по крайней мере, с двумя запущенными тестовыми файлами.

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

Наблюдение в консоли:

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

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

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

Watch Usage: Press w to show more.

Если я удалю журнал консоли, визуально «RUNS» перезапишется, как и предполагалось:

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

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

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

Watch Usage: Press w to show more.

Если я добавлю 3 журнала консоли:

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


 RUNS  tests2/other-tests.js

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

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

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

Watch Usage: Press w to show more.

Версия узла:

30656 % node --version
v8.11.2

Я думаю, что @spion оттачивает это. Хорошая легкая реплика.

Могу подтвердить, что это происходит на Node v8.11.1 LTS и происходит только в режимах watch и watchAll . без режимов часов все нормально.

У меня такая же проблема с Node v10.6.0 и Jest 23.4.1.

Да, я тоже. Только что обнаружил, что -w 1 снова запускает ведение журнала, что соответствует гипотезе @spion .

узел 8.11.3
шутка 23.4.0

Я обнаруживаю эту проблему или, по крайней мере, аналогичную проблему, когда включаю сопоставление регулярных выражений файлов (нажатие p в режиме watch ). При включенном параметре all журналы печатаются должным образом. Обратите внимание, что --verbose здесь нет.

Образец 1

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

При просмотре all (выводит как log s, так и error s:

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

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

В режиме file regex (распечатываются только первые log , а не error s):

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

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

Образец 2

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

all (выводит как log , так и error , как и ожидалось):

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

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

watch (с приведенным выше кодом ничего не печатается):

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

Test Suites: 1 passed, 1 total

Образец 3

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

all (выводит все четыре ожидаемых log ):

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

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

watch (только первые два log печатаются с приведенным выше кодом):

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

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

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

Test Suites: 1 passed, 1 total

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

node -v v8.11.2
jest -v 23.4.0

Ниже моя конфигурация шутки в моем package.json

```
"шутка": {
"трансформигнорепаттернс": [
"/узловые_модули/"
],
"файлы установки": [
"/src/setupTests.js"
],
"тестовая среда": "jsdom",
"многословный": правда,
"проекты": [
{
"displayName": " КОМПОНЕНТЫ ",
"файлы установки": [
"/src/setupTests.js"
],
"пути модулей": ["/источник/"],
"тестматч": ["/src/components/__tests__/ / .test.js"]},{"displayName": " РЕДУКТОРЫ ","файлы установки": ["/src/setupTests.js"],"пути модулей": ["/источник/"],"тестматч": ["/src/редукторы/__tests__/ /.test.js"]
},
{
"displayName": " ДЕЙСТВИЯ ",
"файлы настройки": [
"/src/setupTests.js"
],
"пути модулей": ["/источник/"],
"тестматч": ["/src/actions/__tests__/ */ .test.js"]
}
]
},

Here are my dependencies

"зависимости": {
"babel-core": "^6.26.3",
"вавилонская шутка": "^23.4.0",
"babel-loader": "^7.1.5",
"babel-preset-env": "^1.7.0",
"babel-preset-реагировать": "^ 6.24.1",
"дотенв": "^6.0.0",
"экспресс": "^4.16.3",
"шутка": "^23.4.0",
«реагировать»: «^ 16.4.1»,
"реагировать-дом": "^ 16.4.1",
"реагировать-редукс": "^ 5.0.7",
"реагировать-скрипты": "1.1.4",
"редукс": "^4.0.0",
"регенератор-время выполнения": "^0.12.0"
},

output from just running jest

PASS REDUCERS src/reducers/__tests__/comments/index.test.js
✓ обрабатывает действия типа SAVE_COMMENT (4мс)
✓ обрабатывает действие с неизвестным типом

ПЕРЕДАЧА ДЕЙСТВИЙ src/actions/__tests__/ index.test.js
сохранитьКомментарий
✓ имеет правильный тип (1 мс)
✓ имеет правильную полезную нагрузку (1 мс)

ПЕРЕДАЧА КОМПОНЕНТОВ src/components/__tests__/App/index.test.js
✓ Должен показывать список комментариев (5 мс)
✓ Должен показывать поле для комментариев (1 мс)

ПЕРЕДАЧА КОМПОНЕНТОВ src/components/__tests__/CommentBox/index.test.js
✓ имеет текстовую область (23 мс)
✓ есть кнопка (3мс)
текстовая область
✓ имеет текстовую область, которую пользователи могут вводить (9 мс)
✓ при отправке формы текстовое поле очищается (5 мс)

ПЕРЕДАЧА КОМПОНЕНТОВ src/components/__tests__/CommentList/index.test.js
✓ создает один LI на комментарий (32 мс)

Наборы тестов: 5 пройдено, всего 5
Тесты: 11 пройдено, всего 11
Снимки: всего 0
Время: 3,79 с
Запустил все наборы тестов в 3 проектах.
console.log src/components/__tests__/CommentList/index.test.js:26
0

console.log src/components/__tests__/CommentList/index.test.js:27
Тестовое задание

```

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

→ узел --версия
v8.11.3

→ npx шутка --версия
23.4.1

Попробовал с чистой установкой, все работает.

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

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

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

выход:

Поэтому я подумал, что проблема может быть связана с моей конфигурацией шутки:

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

Мой инстинкт подсказывал мне проверить verbose и после удаления все в порядке.

резюмировать

jest версии 23.4.1 с конфигурацией verbose , установленной на true , приведет к поглощению вывода консоли.

предложить изменить поток вывода по умолчанию на stdout : https://github.com/noscripter/jest/pull/1

Опять сломался?! Почему это продолжает ломаться?

Я работал над этим с помощью:

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

😬

Если у вас есть verbose: true в package.json или вы запускаете jest с флагом --verbose (или с обоими?), попробуйте удалить их.

Ничего, это уже не помогает.

Я часто вижу вывод журнала за долю секунды до того, как полная сводка теста будет напечатана на консоли. Мне приходится console.log примерно 4-5 раз подряд, чтобы отобразить вывод, и даже тогда последний журнал будет обрезан на полпути (например, при печати большого объекта будет отображаться только первая половина). быть видимым в последнем распечатанном журнале).

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

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

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

console.log работает, если вы запускаете только определенный тестовый файл

yarn test <your-test-file-name>

например
yarn test FormValidator

К вашему сведению, я запускаю свою реплику с помощью следующей команды:

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

Это zsh - вам может понадобиться script -qfce в bash

а затем я просмотрел журнал с помощью cat -vet raw.log . Вот результаты:

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

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

Конечный результат выглядит так:

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


 RUNS  tests2/other-tests.js

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

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

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

Строка console отсутствует, а pass написан на две строки слишком далеко, вероятно, из-за переплетения с console.log, который не принимается во внимание при переходе вверх для отображения «PASS».

редактировать: добавлено это резюме в суть для удобного поиска и обработки: https://gist.github.com/spion/bbb34c5abc1230a37ad5f4f01336b8df

ps Чтобы воспроизвести это с текущим мастером, может потребоваться некоторое принуждение. Когда вы входите в режим просмотра, нажмите и удерживайте некоторое время "a" - в какой-то момент console.logs начнет выходить из-под контроля (появляться в неожиданных местах и ​​в неожиданные моменты времени)

Также я забыл - я на Ubuntu Bionic, если это имеет какое-то значение в поведении терминала WRT:

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

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

Что бы это ни стоило, я вернулся к [email protected] , и это решило проблемы, с которыми я столкнулся, когда итоговый вывод теста записывался поверх вывода консоли в [email protected] .

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

Jest monkey исправляет методы записи потоков stderr и stdout процесса с помощью собственного средства записи. Этот писатель записывает вывод jest-cli Status.js, который содержит такие вещи, как количество выполняемых тестов, индикатор выполнения, прошедшее время и так далее.

Всякий раз, когда в этом потоке есть инструкция записи, эта инструкция заменяется инструкцией «удалить» для состояния (повышение с использованием управляющих кодов ANSI), исходной записью и инструкцией «записать статус снова». Таким образом создается иллюзия, что статус всегда находится внизу экрана, а текст прокручивается над ним.

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

Однако параллельный запуск тестов (используемый в режиме наблюдения, который устанавливает для параметра runInBand значение false) запускает другие рабочие процессы. Эти рабочие процессы настроены так, чтобы «наследовать» поток stdio исходного процесса. К сожалению, это не означает, что они наследуют исправленную версию, которая обновляет статус! Если эти записи произойдут, они будут

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

Чтобы убедиться, что пропатченная версия получает эти записи tty, необходимо переключить потоки дочерних процессов из режима «наследования» в режим «конвейера». Таким образом, выходные данные процесса доступны в виде потоков в дочернем процессе вместо прямого перехода к основному stdout/stderr. Нам также нужно вручную направить потоки:

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

значительно снижает это число, но оно все еще довольно велико:

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

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

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

пожалуйста, исправьте, это действительно снижает производительность с помощью шутки

Понижение до [email protected] возвращает вывод журнала консоли. Пришлось установить --env node, чтобы заставить его работать. Пожалуйста, исправьте это.

В настоящее время кажется, что единственный способ сделать ведение журнала консоли надежным — это записывать одно и то же 3-4 раза подряд. Jest заблокирует только определенное их количество. Все еще очень раздражает.

Есть ли какие-либо обновления по этому поводу? Я использую jest 23.4.1 и node 9.11.1, и иногда я получаю вывод журнала консоли, а иногда нет.

Два года отсутствия журналов консоли сделали меня лучшим разработчиком. Спасибо команде Jest!

Я не могу поверить, что это все еще проблема. Почему вопрос закрыт?

Я имею в виду, кто когда-либо захочет отлаживать свои неудачные тесты, верно?

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

FWIW, обходной путь --verbose=false работает для меня. В моем package.json :

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

Некоторые другие наблюдения:

• Удаление --env=jsdom (не вариант для моего реального приложения) заставило его работать без --verbose=false.
• Запуск теста напрямую с помощью шутки (а не через сценарии реагирования) также заставил его работать.
• Когда утверждение терпит неудачу, и вы получаете гораздо больше результатов от шутки, гораздо больше журналов вашей консоли также перезаписывается.

Привет, ребята/девушки,
Я также столкнулся со знаменитой проблемой журнала консоли jest при тестировании в режиме --watch.
Решение состояло в том, чтобы использовать --watchAll вместо --watch. Сводка тестов стала безобразнее, но логи показывали как положено.

macOS Высокая Сьерра
узел v8.11.3
шутка: 23.6.0
ц-шутка: 23.10.4

Для меня это в beforeAll

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

и это в оболочке сделало работу:

yarn test > test.log

Для меня переход на mocha решил проблему. Переключиться очень тривиально, так как DSL очень похож. Вы даже можете продолжать использовать ожидаемую библиотеку JEST: https://www.npmjs.com/package/expect

Это почти так же просто, как удалить jest и установить mocha .

Изменить: спам или нет, это самое простое решение.

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

В любом случае, сейчас я использую следующее:

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

Вы должны спамить свой выход.

Подтверждено, что --verbose=false устраняет проблему.

--verbose=false у меня не работает с версией 23.6.0

OMG это боль :/ ноябрь 2018

Пожалуйста, откройте этот вопрос повторно

попробуйте установить silent: false в jest.config.js ... в моем случае мне это помогло

Ни одно из решений не работает.
NodeJS: v8.12.0
Шутка: v23.4.1

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

Пример при попытке выйти из фиктивного вызова:

expect('hello').toEqual(childFunc.mock.calls[0]) выводит:

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

Запуск Jest с флагом --watch.
Шутка версия 23.5.0
Версия узла 8.11.3

Это достойный пример того, как «слишком много волшебства» происходит под капотом, и последствия этого, когда что-то идет не так. Я не уверен, что группировка вывода console.log стоит полутора лет отсутствия операторов console.log. 😕

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

Мой «обходной путь» заключается в том, что большая часть логики использует log4js , поэтому там, где я подгоняю Jest к коду на стороне сервера, я хорош. К сожалению, у меня есть большой объем кода на стороне клиента, где я обычно копирую и вставляю четыре копии каждого console.log , так как в конце концов кажется, что одна из них появляется.

Использование expect для логирования информации — хороший обходной путь, если вы логируете из теста (тем более, что вы можете создать для него фрагмент с ключевым словом вроде logjest в своем редакторе), но это терпит неудачу всякий раз, когда вам нужно копать глубже и регистрировать из реальных функций, которые вызывают ваши тесты.

Как насчет CI=true yarn run test ?

Извините за то, что я сказал ранее, но он хорошо работает без заголовка тестовых случаев, я имею в виду, что без опции «--verbose», я думаю, что --verbose выполняет какое-то форматирование и заменяет поток stdout.
Итак, для меня я был как 2 месяца, и все работает хорошо.
И если кто-то хочет использовать эту опцию, просто добавьте ее к вашим командам npm следующим образом: npm run test:integration --watchAll --verbose --coverage --etc

Могут ли люди с проблемой проверить [email protected] ? Он включает в себя # 6871

@jamesta696 Привет, я думаю, что вам нужно публиковать такие вопросы на StackOverflow, используя здесь тег «шутка», потому что здесь обсуждаются «проблемы», тем не менее, я знаю, что кто-то может вам помочь, но проблема здесь может быть закрытым, потому что основной вопрос не обсуждается.
А пока я не могу дать вам ответ на этот вопрос, потому что я не разрабатываю что-то для реакции и фронтенда, также я не являюсь участником jest, но давайте попробуем следовать правилам.

@SimenB Я обновил шутку (до указанной вами версии) и попытался разместить в своем проекте несколько операторов console.log , в которых возникла проблема. Пока это кажется исправленным: появляются все console.log s. Я буду продолжать использовать его и дам вам знать, если я столкнусь с проблемой снова.

К вашему сведению: я использовал (и до сих пор) использую jest --watchAll

@tobyhinloopen Круто увидеть доказательство прогресса, в котором упоминается @SimenB .

это потрясающе @tobyhinloopen!

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

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

+1. тоже могу подтвердить. рад видеть, что это работает. хорошая работа, шутники! 😄

Я тоже могу подтвердить! Это как Рождество. 🎅

😃

просто не нужно ждать, пока обновится приложение create-реагировать

Я запускаю шуточную версию 24.0.0 , но все еще не вижу console.log или console.error . Интересно, что я могу делать неправильно.

Убедитесь, что они не издеваются

Это действительно странно. Кажется, есть проблема с асинхронной обработкой. Я не могу заставить отображать ошибки. Даже если завернуть в блоки try/catch , я не вижу ошибки.

Параметр generator точно правильный. Если я удалю вызов асинхронной функции, он зарегистрируется правильно. Он также возвращает правильную строку, когда она находится вне цикла for.

Версия Jest 24.0.0 , узел 10.5

@tiborsaas Ваш тест, вероятно, завершится до запуска console.log .
Если вы хотите дождаться итерации changedGenerators , вам понадобится что-то вроде

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

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

Изменить: на самом деле при построчной отладке я знаю, что проблема с

const archives = await fs.readdir(archiveDir);

Однако эта шутка связана с регистрацией вещей. Я не хочу прерывать разговор.

Возможно, вы все еще сталкиваетесь с ошибкой, просто хотели указать (не зная вашего точного кода), что, как правило, плохая идея — разветвлять кучу обещаний, подобных этому, не дожидаясь их, потому что они могут быть отклонены после завершения вашего теста: )

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

К сожалению, подход Promise.all ничего не исправил.

Вы использовали map вместо forEach ? Суть в том, чтобы вернуть массив промисов в Promise.all

@SimenB да, я знаю.

Если и есть ошибка, то я ее не вижу.

@tiborsaas Вы не ждете завершения Promise.all : используйте await Promise.all(...)

Тоже так делал, тот же результат. :(

что, если вы добавите await new Promise((resolve) => setTimeout(resolve, 1000)) ниже promise.all ?

Можете ли вы открыть новый выпуск с репродукцией? Я считаю, что проблема, о которой сообщает OP, исправлена, пока вы видите другую (независимо от того, правильно ли вы обрабатываете асинхронность или нет, вы все равно должны увидеть оператор журнала)

Да, это действительно странно, что-то вроде

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

обычно все еще каким-то образом печатается

Он использует функцию обратного вызова в качестве второго аргумента Promise.all([...], callback) . Он должен использовать Promise.all([...]).then(callback) . Возможно, это решит его проблему, я думаю, что второй аргумент .all игнорируется и никогда не выполняется (поэтому ваши журналы никогда не будут выполнены). @tiborsaas

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

Да, это неправильно, но отчеты журнала все равно должны отображаться

@SimenB Нет, второй аргумент игнорируется.

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

Да, запутался, извините. Спасибо @tobyhinloopen

const lol = await Promise.all(versions); работал как положено.

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

ПР: # 7731

Я использую https://www.npmjs.com/package/debug для ведения журнала. Будет ли это работать с Jest?

Нет, пока мы не сделаем #6524.

Я бы рекомендовал издеваться над debug в ваших тестах и ​​использовать console.log , если вы хотите их увидеть.

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

--verbose сработало для меня. До использования --verbose некоторые, но не все сообщения терялись. Я использую узел v10.15.3 и jest v21.2.1.

Для меня все еще проблема, журналы консоли не отображаются в Jest.

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

А у меня работает просто отлично 🤷‍♂️. Пожалуйста, опубликуйте репродукцию, мы можем исследовать. Мы не волшебники, мы не можем видеть ваш код, который не регистрирует вывод.

на самом деле, после расследования журналы, связанные с тестированием API (например, супертестом), не работают. ожидал :/

@thymikee Это происходит непоследовательно, поэтому его очень сложно воспроизвести. пример:
следующие запуски, выбрав один файл из тестов (опция p)

• console.log('pantz') (работает)
• изменить console.log(myObject) (не работает)
• изменить его, чтобы соответствовать (не работает)
• изменить на console.log('pantz') (не работает)
• изменить подходит к нему (не работает)
• перезапустить шутку (не работает)
• изменить его, чтобы соответствовать (работает)

Теперь я попытался воспроизвести те же шаги, и результат противоречив.

Предоставьте образец репозитория, где он не работает, чтобы ребята из JEST могли помочь в отладке. @кресли

Существует также множество пользовательских ошибок, в основном отсутствующих await или иным образом асинхронных console.log .

Я постараюсь найти время, чтобы воспроизвести это тогда. До этого я обнаружил, что мои журналы съедены результатами, как вы можете видеть ниже. Перед появлением FAIL вы можете увидеть мои 2 журнала там. А также стоит отметить, что удаляются только 2 лога. Если я добавлю 10 журналов друг под другом, будет показано 8. Я думаю, это хорошее начало :)

Между тем, если вам нужно универсальное исправление, которое просто работает, вы можете использовать что-то вроде winston для входа как в файл, так и в консоль. Даже если ваши консольные сообщения не отображаются, они записываются в файл.

С winston вы можете настроить то, где вы хотите регистрироваться, и он поддерживает несколько транспортов, и транспорты, которые вы можете реализовать самостоятельно.

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

logger.error(stuff)

Может быть, вы даже можете сделать что-то грязное, например, глобально переопределить console.* в регистраторе Winston.

@kresli какая версия твоей шутки? Это похоже на поведение v23

Это постоянно происходит со мной с jest v^24.6.0 и node v10.14.2 . Есть идеи, почему?

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

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

Спасибо за быстрый ответ!
Это будет сложно, потому что текущий репозиторий является частным в моей организации... Я дам вам знать, если доберусь до него :)

Это постоянно происходит со мной с jest v^24.6.0 и node v10.14.2 . Есть идеи, почему?

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

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

В понедельник, 5 августа 2019 г., в 12:43 Норман Энмануэль[email protected]
написал:

Спасибо за быстрый ответ!
Это будет сложно, потому что текущий репозиторий является частным в моей организации... Я позволю
ты знаешь, если я доберусь до него :)

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

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/facebook/jest/issues/3853?email_source=notifications&email_token=AB6F4PAE3CHUMEBP7IYXRPLQC7Y2DA5CNFSM4DPZ3JSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3RI3PY#issuecomment-
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AB6F4PFXDSRHBW5CMTT2DKDQC7Y2DANCNFSM4DPZ3JSA
.

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

Конечно:

шутка

^24.8.0

узел -v

v10.16.0

И это некоторые сценарии npm, которые я использую для запуска e2e, интеграции, модуля и принятия:

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

Это jest.config:

"use strict";

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

Надеюсь, поможет.

Я постараюсь найти время, чтобы воспроизвести это тогда. До этого я обнаружил, что мои журналы съедены результатами, как вы можете видеть ниже. Перед появлением FAIL вы можете увидеть мои 2 журнала там. А также стоит отметить, что удаляются только 2 лога. Если я добавлю 10 журналов друг под другом, будет показано 8. Я думаю, это хорошее начало :)

@kresli Что у вас здесь за строка состояния и вывод времени? Когда я запускаю свой набор тестов, я вижу _RUN HARNESS test-harness/index.js_ и больше ничего, пока все не запустится. Затем я вижу сообщение console.log в самом конце, и строка с _RUN HARNESS..._ меняется на _ОБУЗДАТЬ...._

Обновление: пожалуйста, проигнорируйте, проблема оказалась в моем коде

Все еще сталкиваюсь с этим с node v12.16.1, jest 25.5.4, typescript 3.8.3 на MacOS. Пробовал рекомендации по использованию --runInBand, отключению/включению verbose, использованию --silent=true, не помогло.