Mocha: Подавить вывод `console.log` из успешных тестов

@justinmchase Только через плагины, если они есть. Нет для этого места в ядре мокко, имо.

Проксирование console.log подвержено ошибкам. На первый взгляд, самая безопасная ставка - это создание утилиты log которая хранит массивы argument вызовов для последующей регистрации их в тесте 'fail' (через подключение к mocha ).

Спасибо за ответ! Звучит вполне разумно.

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

Это старая проблема, но я нашел этот ответ StackOverflow полезным. Проверка this.currentTest.state в обработчике afterEach в корневом наборе выглядит как хороший способ перехватить все ошибки теста.

// On the root suite - so outside any describe() block
afterEach(function() {
  if (this.currentTest.state === 'failed') {
    // a test just failed
  }
  if (this.currentTest.state !== 'passed') {
    // a test, before(), or beforeEach() hook just failed
  }
});

В прошлом об этом было довольно много разговоров. Возможный обходной путь был предложен здесь: https://github.com/mochajs/mocha/issues/1582#issuecomment -87464832

должен быть флаг --errors-only, который будет означать, что единственный вывод Mocha будет для неудачных тестов, но не уверен, существует ли он.

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

var debug = require('debug')
var log = debug('myapp')

log('useful debugging output')

Затем при запуске:

$ mocha # no console output from app

или

$ DEBUG=myapp mocha # prints out console output from app

Объедините это с аргументом --grep чтобы получить консоль только после одного теста.

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

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

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

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

Например:

// console.js
import { App } from './app'

const app = new App()
app.on('started', () => console.log('application started...')
app.on('done', () => console.log('application done.')
app.run()

// app.spec.js
import { App } from './app'
import sinon from 'sinon'
import { expect } from 'chai'

it('runs successfully', (done) => {
  const started = sinon.stub()
  const app = new App()
  app.on('started', started)
  app.on('done', () => {
    expect(started.called).to.be.true
    done()
  })
  app.start()
})

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

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

mocha test | bunyan -l error

@justinmchase Мне очень нравится эта идея консольного интерфейса ... Это кажется очевидным, если подумать.
Мое текущее решение - издеваться над console.log с помощью https://github.com/sinonjs/sinon , строить ожидания относительно того, что он должен регистрировать, а затем вызывать исходный console.log через то, что не ожидается. Вы можете увидеть такой пример здесь .

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

Я не могу поверить, что это не "вещь", я новичок в использовании TDD, и одна из первых вещей, которые меня раздражают, - это
сбой теста. В итоге я вставляю console.log в тесты для проверки состояний объекта и т.д., а затем, когда все исправлено, я снова удаляю все журналы, поскольку он выводит результаты из поля зрения окна консоли.
Я бы хотел что-нибудь вроде onTestFail( console.log(....) );

Я согласен. Во время разработки я часто использую сложные объекты console.log , например React props из компонентов HOC, таких как Apollo. Это отлично работает в браузере, где объект можно сворачивать и разворачивать, но только один из них во время тестов может сделать вывод практически бесполезным.

Как и @sladec, я смущен тем, что это не обычная проблема со встроенным решением, но это касается многих проблем, с которыми я столкнулся при внедрении Mocha и TDD.

В любом случае другой обходной путь, если вы используете Webpack, может заключаться в подавлении console.log в вашей тестовой конфигурации. Быстрый поиск предлагает использовать UglifyJSPlugin или что-то вроде webpack-strip . Но я не тестировал ...

Опять же, @ViggoV, я думаю, вам следует использовать библиотеку отладки вместо console.log непосредственно для отладки приложения. Затем, чтобы передать данные на консоль в вашем приложении, обработайте события во интерфейсном компоненте, который регистрируется в консоли.

Например:

import debug from 'debug'

const log = debug('server');

export function server () {
  // ...
  log('server started...')
}

Теперь, когда вы запустите это локально или в тесте, по умолчанию ничего не будет записано в stdout. Чтобы разрешить запись этого отладочного вывода в стандартный вывод, вы должны включить его с помощью переменной среды.

Например:

$ npm test              # <> is emitted
$ DEBUG=server npm test # <server started...> is emitted

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

Например, oas3-tools 2.0.2 содержит дампы на
./node_modules/oas3-tools/dist/middleware/swagger.router.js:36:
console.log("handlerCache[handlerId]: "); console.log(handlerCache[handlerId]);

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

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

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

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

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

https://www.npmjs.com/package/mocha-suppress-logs

Вот пример кода, который скроет журналы успешных тестов и покажет только те тесты, которые не прошли:

const suppressLogs = require('mocha-suppress-logs');

describe('Something', () => {
  suppressLogs();

  it('should do something', () => {
    // test code
  });
});

Вы также можете сделать это глобально по всему набору тестов.