Я наблюдаю ту же проблему. Тесты пройдут а то мокко просто зависнет. См. Мой Travis CI:
https://travis-ci.org/mkrufky/node-dvbtee/builds/282593109

Еще я заметил такую ​​же проблему на video-dev / hls.js - мокко просто зависает после прохождения тестов:
https://travis-ci.org/video-dev/hls.js/builds/282590422

Ребята, вы читали примечания к выпуску? https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit

Благодарю. к сожалению, веб-сайт мокко не обновляется с этим критическим изменением. В cli args об этом не упоминается.

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

В примечаниях к выпуску предлагается использовать why-is-node-running за исключением того, что он не работает из-за https://github.com/mafintosh/why-is-node-running/issues/7

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

Привет всем,

Прежде всего, я хочу извиниться за грубый путь обновления в этом пункте - мы определенно согласны с тем, что Mocha должен сообщать пользователю, что поддерживает выполнение тестов (и тогда ему даже не нужно будет держать процесс открытым; он может просто быть причиной для возврата к неудаче после того, как они закончили), но пока не нашли полностью удовлетворительного способа сделать это. Версия 4 не получила того количества времени, которое мы хотели бы вложить в нее, так как это было вызвано отказом нашего CI из-за изменений в установщике PhantomJS 1.x (package-lock.json, вероятно, предотвратил бы это, если бы у нас был он настроен заранее, но мы все еще не можем заставить его работать ). why-is-node-running был единственным инструментом, который, как мы обнаружили, помог, но мы не думаем, что сможем его интегрировать (между требованием --expose-internals и отсутствием хорошего способа программного получения его вывода); Я обнаружил, что это работает, если вы выполните пару шагов:

• запустите Mocha с помощью --expose-internals ( node --expose-internals node_modules/mocha/bin/_mocha )
• сделайте свой первый тестовый файл (например, указанный в mocha.opts ) содержащий (или, по крайней мере, начинающийся с) after(require('why-is-node-running'))

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

Также извините за отсутствие документации по сайту - мы обновим ее как можно скорее. (Как только # 2987 будет готов, мы даже сможем сделать его автоматической частью нашего сценария версии / публикации!)

@ScottFreeCode

borisov<strong i="7">@glossy</strong>:~/test/mocha $ node --version
v6.11.3

borisov<strong i="8">@glossy</strong>:~/test/mocha $ ./node_modules/.bin/mocha --version
4.0.0

borisov<strong i="9">@glossy</strong>:~/test/mocha $ ./node_modules/.bin/mocha --expose-internals test.spec.js 
  error: unknown option `--expose-internals'

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

Это работает:

node --expose-internals ./node_modules/.bin/mocha test.spec.js

Правильно, извините, я не понял этого - --expose-internals - это параметр узла, который можно использовать, запустив node --expose-internals ./node_modules/mocha/bin/_mocha вместо ./node_modules/.bin/mocha . Это также то, что мы можем исправить, поскольку Mocha передает определенные флаги в Node, и мы можем добавить к этим флагам --expose-internals .

Созданы mochajs / mochajs.github.io # 81 и # 3045 для отслеживания обновления документации и флагов узла Mocha соответственно. Сохраним этот вопрос по крайней мере до обновления документации.

@ScottFreeCode , возможно, вы захотите упомянуть, что --expose-internals работает только для узла <= 6. Надеюсь, люди смогут временно перейти на узел 6, чтобы они могли найти, какой таймер нужно отменить или отменить , или сокеты, которые должны быть unref 'ed. Вы также можете указать людям на хуки after и afterEach для очистки.

(есть ли глобальный хук «после», который вызывается mocha после завершения всех тестов?)

В любом случае, я ценю помощь и спасибо за Mocha!

вы можете упомянуть, что --expose-internals работает только для node <= 6.

Вы уверены? Я тестировал с Node 8.6.0. Хотя и не во всех ОС, так что, думаю, мне стоит запустить все имеющиеся у меня коробки и перепроверить ...

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

Вы уверены? Я тестировал с Node 8.6.0. Хотя и не во всех ОС, так что, думаю, мне стоит запустить все имеющиеся у меня коробки и перепроверить ...

Это «работает» в том смысле, что запускает вывод модуля, но на самом деле не дает мне много информации, независимо от версии Node.js.

Я собираюсь добавить некоторые обновления на сайт, но, пожалуйста, ознакомьтесь с моими предстоящими комментариями к # 3045.

Это «работает» в том смысле, что запускает вывод модуля, но на самом деле не дает мне много информации, независимо от версии Node.js.

Он дает полезную трассировку стека для setTimeout и setImmediate , но не дает никакой реальной информации для других вещей, таких как сервер прослушивания (как я недавно обнаружил, пытаясь понять, как он делает то, что он делаю). Пример «async-dump» в сущности имеет реальное преимущество с точки зрения работы для всего (и не требует --expose-internals ), хотя его можно использовать только в более новых версиях Node.

Я полагаю, что мой общий совет был бы: «Если вы выдергиваете волосы, просто добавьте --exit и расслабьтесь». Тогда не используйте его в своем следующем проекте: wink:

... а вот документы

Извините, что снова комментирую закрытый PR, но здесь может быть удобное решение:

Можно было зарегистрировать предупреждение об изменении поведения после того, как бегун завершил работу в течение 3 секунд или около того, но процесс не завершился.
Просто нужно добавить setTimeout() после завершения бегуна и вызвать timeout.unref (), чтобы убедиться, что этот тайм-аут не препятствует завершению процесса. Если время ожидания истекло, пришло время для предупреждения 😉

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

Если у вас все еще есть проблемы и why-is-node-running не работает, попробуйте wtfnode .

Этот пакет работал у меня намного лучше.

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

Я случайно обнаружил это изменение с помощью новых тестов, которые заставили меня убедиться, что я вызвал redis.quit () в функции after (), и я определенно доволен новым поведением, которое мне кажется правильным и подходящим.

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

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

AFAICT, это как-то связано с необработанными отказами обещаний. Но простите меня, если вы не выполните обещание, данное тесту Mocha, то Mocha не будет ни успешным, ни продолженным (если установлено --bail ) из этого теста, верно? Так что это должно быть какое-то плохо реализованное вложенное обещание, у которого нет обработчика отклонения, но содержащий код все равно должен разрешаться.

Если это так, то я не понимаю, как Mocha должен обнаруживать эти проблемы. И если осуществление какой - то магии , чтобы обнаружить те проблемы, которые могут сделать ток (правильно написанные) тесты зависнуть, то , что магия должна быть отказ в поведении, а не отказ из одного - то есть --no-exit , а не --exit .

Я смотрю на все свои тесты с использованием официального драйвера node-mongodb-native, который зависает, потому что этот драйвер объединяет соединения и не закрывает их все на .close() , по-видимому, это дизайн. Мои тесты работают правильно, но зависимость - нет (или это так? Я не уверен, что это плохое поведение - иметь устаревшие сокеты или файловые дескрипторы до тех пор, пока скрипт не будет завершен в другом месте - не так ли?). Так что я здесь тестирую? Мой код или чужой? Я думал, что тестирую свою, но, видимо, нет.

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

Если я добавлю process.exit() в последний крючок after() , мои тесты не будут зависать, но тогда они будут ужасно ломаться с --watch (возможно, другими функциями), не только не позволяя мне следить за изменениями, но выталкивает меня в оболочку без курсора.

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

Ура :)

РЕДАКТИРОВАТЬ: Учитывая такое поведение, могу ли я проверить внутри теста Mocha, запускается ли он с помощью --watch чтобы я мог убедиться, что не вызываю process.exit() и не нарушаю работу?

@DanielSmedegaardBuus TL; DR для решения: поместите --exit в файл mocha.opts . (Обычно это решение для всего, что необходимо всегда устанавливать при запуске Mocha, как более общий совет.) Более подробное разъяснение того, о чем это изменение: ниже.

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

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

У меня есть тест API на основе веб-сокетов, который включает открытие и закрытие соединений. Этот API был с ошибками и не закрывал соединения должным образом, но прошел мои тесты, так как тесты действительно не имели возможности утверждать, что базовое соединение было обработано правильно. (Если бы я строго тестировал только свой собственный код, я мог бы проверить его, используя зависимость тем, что я ошибочно считал правильным; я тестировал реальный веб-сокет именно для того, чтобы в первую очередь выявить проблемы с правильностью использования - Я обнаружил эту ошибку, когда переключился на поведение --no-exit (Mocha 3; теперь по умолчанию в Mocha 4) и обнаружил, что если я запустил эти тесты, Node не закроется, потому что соединение с веб-сокетом все еще прослушивает.

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

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

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

Мне очень жаль, но это было очень неприятно. Я просто пытался выяснить, почему мокко не выходит. https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit ссылается на why-is-node-running , так что теперь я пошел, попытался использовать этот модуль, увидел загадочное сообщение "Ошибка: не удается найти модуль" internal / connectedlist '... (трассировка стека) ", и, проследив за кроличьей норой, пытаясь выяснить, почему --expose-internals не работает, я попал на https://github.com/mochajs/mocha/ issues / 3045, чтобы найти предполагаемое решение, но why-is-node-running сообщает мне, что существует 1 известный дескриптор, который держит его открытым, и несколько неизвестных дескрипторов, но ничего не перечисляет.

Возможно , это неподходящее место для обсуждения этого вопроса , но

package.json:

"scripts": {
    "test": "mocha --exit"
}

Это лучшее, что я могу сделать.

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

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

После удаления --exit из моего mocha.opts отклоненные обещания будут надежно регистрировать ошибки и выделять эти ошибки.

Я знаю, много общего боли :) документировано поведение Мокко на самом деле звучит правильно для меня, но даже если мои 5 тестов кажутся достаточно простой, только с помощью узла выборки для тестирования API, я до уверен , why-is-node-running не работает, но я устал от обезьяны по поводу чужого кода, поэтому я думаю, что сейчас я дам себе передышку.

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

рекомендовал бы новый отладчик инспектора узлов ... у него хорошие асинхронные трассировки.

Ура! Оказывается, wtfnode намного лучше result.text() или .json() иначе соединение останется открытым. Запуск wtfnode ./node_modules/.bin/_mocha и нажатие Ctrl-C выявили открытые соединения.

Я думаю, было бы проще, если бы документация рекомендовала этот пакет, а не why-is-node-running .

Еще одно предложение: мне очень нравится идея @andywer о предупреждении о том, что мокко не завершится. Было бы здорово, если бы mocha даже мог каким-то образом использовать wtfnode для перечисления активных дескрипторов, поддерживающих работу узла по прошествии некоторого времени.

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

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

describe('describe', function() { it('it', function(done) { done(); }); });

Резюме: --exit делает работу, --no-exit никогда не закрывает любое испытание.

В моем случае я использую приложение КОА и тестирование с мокко 4 + Supertest.

Мне пришлось просто закрыть сервер вместе с вызовом done соответствии с примечаниями к выпуску «Чтобы избежать ложных срабатываний и улучшить методы тестирования».

До:

request(app.listen())
  .post('/')
  .send(requestSrc)
  .expect({ f: {} }, done)

После:

const server = app.listen()

request(server)
  .post('/')
  .send(requestSrc)
  .expect({ f: {} }, () => {
    server.close()
    done()
  })

Надеюсь, это поможет кому-нибудь.

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

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

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

@evert Не after ?

Есть ли глобальное «после всего», которое выполняется после того, как мокко готов? Возможно, я это пропустил! Не удалось найти в документации.

Да, есть глобальный хук after .

https://mochajs.org/#root -level-hooks

Спасибо! Я пропустил это, извините: / не знал терминов, для которых нужно использовать Ctrl-F.

wtfnode на самом деле не работал для меня. Все, что я мог видеть, это то, что завис какой-то PID, запущенный мокко.

С другой стороны, @boneskull gist работал: https://github.com/mochajs/mocha/issues/3044#issuecomment -351299745. Спасибо!

wtfnode нужно запускать с _mocha , а не с mocha .

Спасибо за --exit . Это исправило для меня.

введите этот скрипт в package.json:
"scripts": {
"тест": "мокко - выход"
}

Я пробовал различные средства, упомянутые в этой теме:

• почему-is-node-running не выводит
• wtfnode производит вывод, но его недостаточно, чтобы определить, где в коде создаются файловые дескрипторы / сокеты / серверы / таймеры.
• ошибки метода отладки async_hooks
• добавление –exit к флагу строки mocha cmd приводит к выходу

Следуйте за @ProfJigsaw и используйте –exit, вот что я делаю. Было бы здорово, если бы с помощью мокко было улучшение, хотя бы способ выяснить, где есть проблемы и как их решить.

Вот для чего нужен отладчик, ИМО. Как бы вы отладили свои собственные сценарии, если бы они никогда не завершались?

https://github.com/GoogleChromeLabs/ndb - классный проект.

Не по теме: мне нравится этот билет, только за информацию об инструментах устранения неполадок, которые он продолжает предоставлять! :)

@borisovg Представьте себе, насколько прекрасным был бы этот билет, если бы он действительно предлагал решение! :)
@boneskull Есть ли функция отладчика "список файловых дескрипторов / сокетов / серверов / таймера", о которой я не знаю?

@mjgs это wtfnode сработало, но только когда я использовал его с двоичным кодом _mocha , а не с mocha one:

$ wtfnode ./node_modules/.bin/_mocha my-shitty-code.spec.js 


  tests
    ✓ some test


  1 passing (5ms)

^C[WTF Node?] open handles:
- File descriptors: (note: stdio always exists)
  - fd 1 (tty) (stdio)
  - fd 2 (tty) (stdio)
- Servers:
  - :::8080 (HTTP)
    - Listeners:
      - request: (anonymous) @ /home/borisov/test/my-shitty-code.js:4
- Intervals:
  - (5000 ~ 5 s) (anonymous) @ /home/borisov/test/my-shitty-code.js:8

@borisovg Спасибо за действительно супер-пример. В моем случае wtfnode показывает, что соединение mongo открыто, но все соединения mongo в моем my-shitty-code.js были закрыты, поэтому проблема откуда-то еще, и wtfnode не дает достаточно информации о том, где это из.

Если wtfnode указывает, что соединение mongo db открыто, то оно открыто. Почему вы думаете, что это неправильно?

@evert Я думаю, вы могли неправильно истолковать то, что я написал

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

Я столкнулся с этой проблемой при написании бессерверной функции, которая взаимодействовала с Firebase. Оказывается, их административный SDK поддерживает открытый дескриптор на неопределенный срок. Благодаря этому изменению (и последующему предложению использовать wtfnode , я смог идентифицировать этот факт и избавить себя от тонны головной боли (и затрат) в будущем.

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

var timers = sinon.useFakeTimers({
    now: new Date().getTime(),
    shouldAdvanceTime: true,
});

Если я забуду timers.restore(); процесс зависнет навсегда.

На основании документации, отправленной сюда @pgilad , для меня есть более чистое решение. Как говорится в документе :

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

Более чистым решением было бы создание глобальной функции after ( after вне любой функции describe ), я бы рекомендовал в отдельном файле, например exit-mocha.js или exit-mocha если хотите. Обратный вызов, отправленный после того, как вы можете принудительно принудительно завершить процесс узла, который завершится без каких-либо ошибок. Файл можно отправить в mocha cli, как если бы это был другой тестовый файл (он может имитировать флаг --exit )

exit-mocha.js или exit-mocha

after('Exit mocha gracefully after finishing all tests execution'. function () {
  // Exit node process
  process.exit();
});

Затем вы можете выполнить тесты мокко, например:

mocha exit-mocha test/**/*.spec.js

или же

mocha exit-mocha.js test/**/*.spec.js

Важно, что если вы используете подстановочные знаки для имен файлов тестов, как я сделал с test/**/*.spec.js , имя файла exit-mocha НЕ соответствует шаблону подстановочных знаков, иначе оно не будет можно будет использовать его как «флаг»

@ vctr90 Это отличное решение, хотя у вас есть точка, в которой в вашем примере должна быть запятая. Кроме того, все это можно кодировать в гольф, чтобы просто:

after('Exit mocha gracefully after finishing all tests execution', process.exit);

Есть ли шанс, что разработчик вмешается, почему добавление этого в Mocha может кому-то повредить (потому что это явно поможет многим людям)?

@machineghost Мне нравится новое поведение по 2 причинам:

1. Практически никакая другая библиотека не выйдет после того, как «сделает свою работу». Например, закрытие сервера Node TCP не вызовет автоматического выхода. Таким образом, он согласуется с другими библиотеками.
2. Если узел не выходит, это означает, что есть события, ожидающие разрешения. Вероятно, лучше попытаться улучшить свой код, чтобы все наладилось после каждого теста. Это также может указывать на утечку памяти.

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

Ваш взгляд на это может быть таким: «Меня не волнуют утечки памяти» или «это не стоит исправлять в моем приложении». Если вы находитесь в этой категории, проще всего сделать mocha.opts и добавить --exit .

Мне просто кажется, что речь идет о создании большего количества шума, а не сигнала: в значительном большинстве случаев ни одно приложение не станет лучше, потому что Mocha завис в конце.

Если Mocha будет по умолчанию, похоже, что по умолчанию он должен заканчиваться, когда тесты (и все вызовы after / afterEach ) будут завершены. Если вы не сделаете это просто для того, чтобы сказать людям: «Эй, ваша искусственная среда тестирования искусственная», это не принесет пользы большинству (или даже приличному меньшинству) пользователей.

Если люди действительно хотят отлаживать незакрытые соединения, то, похоже , вы должны предоставить такую ​​возможность. Но все остальное время, действительно ли полезно пользователям библиотеки сбивать с толку всех остальных (что означает сказать) «вы находитесь в тестовой среде, и одна из миллиардов возможных вещей открыта»?

Другими словами, если вы собираетесь сказать 99% людей, которые сталкиваются с этим, «просто используйте --exit », тогда, возможно, --exit не должно быть специальным вариантом, который вам нужно предоставить ... может быть, поведение по умолчанию должно обслуживать 99% пользовательских случаев (при этом, конечно, по-прежнему предоставляется _option_ --tell-me-if-I-have-unclosed-stuff-in-my-testing-environment-and-that-is-actually-what-i-am-trying-to-find-out )?

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

PS Я только что наткнулся на это: https://stackoverflow.com/questions/54999115/where-to-destroy-knex-connection. Если вы посмотрите на второй ответ, это поведение в Mocha напрямую заставило как минимум одного пользователя (это не я, и я клянусь, что не знаю их: я просто нашел это по удаче после того, как сделал свой последний пост), чтобы добавить неправильный нетестовый код (эта «функция» заставила их ошибочно подумать, что необходимо вызвать knex.destroy() в своем приложении).

Сводная версия:

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

Хороший человек: цитирует документы

Смущенный человек: если я не вызову knex.destroy (), мой скрипт зависнет. Тогда что это значит, что нам не нужно явно вызывать knex.destroy ()

Хороший человек: Ах, вы только что упомянули, что это для Mocha. Для обычного использования сервера вам не нужно разрушать пул соединений - для Mocha вам может потребоваться глобальный перехватчик разрыва, см. Futurestud.io/tutorials/…

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

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

Извините, я принял вашу усталость за честный вопрос. Сожалею, что ответил. Может быть, разработчики смогут заблокировать эту ветку.

"mocha --reporter mocha-allure-reporter ./tests/controllers --exit" у меня сработало. Действительно, --exit - очень хорошее решение. В своем проекте я использую версию 5.2.0 .

Есть ли способ получить эквивалентный эффект от использования флага --exit при использовании мокко « программно» ?

Я не вижу задокументированной опции для exit / noexit или общего способа передачи строки флага при использовании API NodeJS.

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

const mocha = new Mocha({
    exit: true,
});

но добиться желаемого эффекта не удалось.

Беглый просмотр https://github.com/mochajs/mocha/blob/master/lib/mocha.js, похоже, показывает, что эту опцию нужно добавить не только в документацию, но и в источник.

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

Как именно вы его проходите? Это мой сценарий package.json

"scripts": { "test": "istanbul cover node_modules/mocha/bin/_mocha --exit test/Testcases/ " } и не работает

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

Как именно вы его проходите? Это мой сценарий package.json

"scripts": { "test": "istanbul cover node_modules/mocha/bin/_mocha --exit test/Testcases/ " } и не работает

Была такая же проблема, и я думаю, что я не единственный. Мне просто нужно было двигаться - выйти в конце.
Это не сработало:
обложка istanbul ./node_modules/mocha/bin/_mocha --exit - test / .test.jsЭто сработало у меня:обложка istanbul ./node_modules/mocha/bin/_mocha - test / .test.js --exit

exit ничего не делает при программном запуске Mocha, fwiw. процесс принудительно завершается оболочкой CLI, а не библиотекой Mocha.