我看到了完全相同的问题。 测试将通过，然后摩卡挂起。 查看我的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

谢谢。 不好的意思是，此重大更改未更新摩卡网站。 那里的客户端没有提及。

除了提供快速修复（使用--exit ）之外，我确实同意他们将找到错误测试的核心问题留给了用户。 我现在正在为此苦苦挣扎，但是在升级主要版本时，请确保阅读发行说明，而不是盲目升级

发行说明建议使用why-is-node-running但由于https://github.com/mafintosh/why-is-node-running/issues/7而无法使用

也被这个击中。 我了解更改为default背后的why-is-node-running被放弃和破坏，这可能不是最用户友好的更改。

大家好，

首先，对于这一点，我想为粗略的升级途径表示歉意-我们绝对同意，Mocha应该告诉用户什么使测试保持运行（然后它甚至不需要保持流程开放；它可以是在失败后返回失败的原因），但尚未找到一种完全令人满意的方法。 由于PhantomJS 1.x的安装程序发生了更改，我们的CI失败提示版本4没有得到我们想要投入的时间（如果有的话，package-lock.json可能会阻止这样做）它是预先设置的，但我们仍然无法使其正常运行）。 why-is-node-running是我们发现可以提供帮助的工具，但是我们认为我们无法将其集成（在--expose-internals与缺乏以编程方式获取其输出的好方法之间）； 我发现如果您遵循几个步骤，它确实可以工作：

• 使用--expose-internals （ node --expose-internals node_modules/mocha/bin/_mocha ）运行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选项，可以通过运行node --expose-internals ./node_modules/mocha/bin/_mocha而不是./node_modules/.bin/mocha 。 这也是我们可以解决的问题，因为Mocha将某些标志传递到Node上，并且可以在这些标志上添加--expose-internals 。

创建了mochajs / mochajs.github.io＃81和＃3045来分别跟踪文档更新和Mocha的Node标志。 至少在更新文档之前，此问题将一直保持打开状态。

@ScottFreeCode您可能要提到--expose-internals仅适用于节点<=6。希望人们可以暂时降级到节点6，以便他们可以找到需要取消或引用的计时器或需要使用的套接字。未引用。 您可能还想将人们指向after和afterEach挂钩进行清理。

（所有测试完成后，mocha是否会调用全局的“ after”钩子？）

无论如何，我感谢您的帮助，并感谢Mocha！

您可能要提到--expose-internals仅适用于节点<= 6。

你确定吗？ 我使用Node 8.6.0进行了测试。 尽管不是在所有操作系统上都可以，所以我想我应该启动我拥有的每个盒子并进行三次检查...

这是一份要点，目前暂时

你确定吗？ 我使用Node 8.6.0进行了测试。 尽管不是在所有操作系统上都可以，所以我想我应该启动我拥有的每个盒子并进行三次检查...

这种“有效”的方式是它触发了模块的输出，但是无论Node.js的版本如何，它实际上并没有给我太多信息。

我将向网站添加一些更新，但请参阅我即将在＃3045上发表的评论。

这种“有效”的方式是它触发了模块的输出，但是无论Node.js的版本如何，它实际上并没有给我太多信息。

它为setTimeout和setImmediate提供了有用的stacktrace，但是对于诸如侦听服务器之类的其他东西根本没有任何真实信息（正如我最近发现的那样，我试图了解它的工作方式）在做）。 要点上的“异步转储”示例在处理所有内容方面都具有真正的优势（并且不需要--expose-internals ），即使它只能在较新版本的Node上使用。

我想我的一般建议是“如果您要拔头发，只需添加--exit并放松一下”。 然后不要将其用于下一个项目：wink：

...这是文档

很抱歉再次对已关闭的PR发表评论，但是这里可能有一个用户友好的解决方案：

在跑步者完成3秒钟左右的时间后，可能会记录有关更改的行为的警告，但该过程并未退出。
在跑步者结束后只需要添加setTimeout()并调用timeout.unref（）即可确保此超时不会阻止进程退出。 如果执行超时，则该发出警告了

我已经考虑过了，但是我很警惕，这会导致报告程序或其他集成出现其他问题……我无法证明它不会。

如果您仍然遇到问题，但是why-is-node-running无法正常工作，请查看wtfnode 。

这个包裹对我来说效果更好。

我可以看到使现有测试突然停止退出的方式令人不安（至少可以说）。 我确实在发行说明中提到了有关新行为的内容。

我自己通过新的测试偶然发现了更改，这迫使我确保在after（）函数中调用redis.quit（），并且我对新的行为感到满意，这对我来说似乎是正确的和适当的。

这次我不需要使用[要点]，但是正如@boneskull所提到的

我必须承认，我不太了解这种新的行为更改背后的参考故障单中的问题。

AFAICT，与未处理的Promise拒绝有关。 但是请原谅，如果您不解决对Mocha测试的承诺，那么Mocha既不会成功也不会继续（如果设置了--bail ），对吗？ 因此，它必须是一些实现较差的嵌套Promise，它没有拒绝处理程序，但是包含的代码无论如何都必须要解析。

如果是这种情况，我看不到Mocha如何检测这些问题。 而且，如果实施某种魔术来检测那些问题，这可能会使当前的（正确编写的）测试无限期地挂起，那么该魔术应该是一种选择加入的行为，而不是一种选择退出的行为，即--no-exit而不是--exit 。

我正在使用挂起的官方node-mongodb-native驱动程序查看所有测试，因为该驱动程序合并了连接，并且并未在.close()上关闭所有连接，这似乎是设计好的。 我的测试行为正常，但是依赖项却没有（或者是吗？我不知道事实是这样的事实：在脚本退出其他地方之前，缠结套接字或文件描述符是不好的行为，对吗？） 那我在这里测试什么？ 我的代码还是其他人的代码？ 我以为自己正在测试自己的，但显然不是。

当然，我可以添加--exit标志，但是下一个家伙可能不会，而且无论哪种方式，我都可以用受测试的优良代码编写出优良的测试，而且仍然有一些随机依赖关系，这似乎是错误的我的测试会无限期地挂起。

如果我在最后的after()钩子中添加process.exit() ，我的测试不会挂起，但是它将被--watch （可能还有其他功能）严重破坏阻止我注意更改，但将我弹出到没有光标的外壳中。

我很可能是这里的无知者（肯定有很多我没有得到，而且很多人都参与其中，所以我倾向于这样想:)），我只是觉得整个事情还不太...对吧...？

干杯:)

编辑：鉴于此行为，我有什么办法可以在Mocha测试中检查是否正在与--watch一起运行，以便我可以确保不调用process.exit()并破坏事情吗？

@DanielSmedegaardBuus TL;解决方案上的DR：将--exit放入mocha.opts文件中。 （作为一般提示，这通常是解决在运行Mocha时始终需要设置的所有内容的解决方案。）有关此更改的含义的更详细说明：下文。

2640涉及承诺拒绝，除了要使它们与非承诺异步测试代码引发的同步异常保持一致之外，它什么也不做，并且尚未实现。

这与测试建立资源，侦听器或正在进行的工作有关，而不是清理它们，而不管其实现和/或测试中是否使用了承诺。 例如：

我有一个针对基于websockets的API的测试，其中包括打开和关闭连接。 这个API有问题，并且没有正确关闭连接，但是通过了我的测试，因为测试实际上没有办法断言基础连接已正确处理。 （如果我只严格测试了自己的代码，则可以以我错误地认为是正确的方式来验证它正在使用依赖项；但是我首先使用真正的websocket进行了测试，以首先发现使用正确性的问题-集成测试以补充单元测试。）当我切换到--no-exit行为（Mocha 3；现在是Mocha 4中的默认值）时，发现了该错误，并且发现如果我运行这些测试，Node不会关闭，因为websocket连接仍在侦听。

（的确，错误可能存在于依赖关系中，而不是您自己的代码中，但是即使那样，在提供给定版本的依赖关系之前了解这一点也很有用-如上文所述，这是首先，它比集成测试更适用于集成测试，但理想情况下，项目应兼有两者。）

当然，这并不总是必要的-在某些情况下，这种性质的资源可能会一直处于活动状态，直到进程被杀死为止，或者即使没有其他真正的资源清理问题，也可能使Node保持活动状态，或者可能是重用单个成员的资源池的一部分，并且不需要整体清理池-在这种情况下， --exit是正确的。 更改默认行为的原因是为了提高此类问题的可见性：以前，您可能永远都不知道尝试--no-exit检查这些类型的错误，现在默认情况下会遇到它们并且如果您确定行为正确（或至少不值得担心），则可以--exit 。

当然，“修复”有一个问题，就是这种情况发生时挂起的信息不多。 我们仍然需要弄清楚我们是否可以集成某种方式以编程方式实际检查仍在运行的事物（这样可以给出适当的警告或错误），该方法将在所有受支持的Node版本上运行，而不会干扰任何仍在运行的事物。在Mocha结束时清理或关闭。

对不起，但这非常令人沮丧。 我只是想找出为什么摩卡咖啡不会退出。 https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit指向why-is-node-running ，所以现在我走了，尝试使用该模块，看到了一条模糊的消息“错误：找不到模块' internal / linkedlist'...（堆栈跟踪）”，然后在尝试找出--expose-internals不起作用的原因之后，我走到https://github.com/mochajs/mocha/ Issues / 3045找到一个可能的解决方案，但是why-is-node-running告诉我，有1个已知的句柄将其保持打开状态，还有一些未知的句柄，但未列出任何内容。

这可能不是提出这个建议的正确位置，但是

package.json：

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

那是我所能做的最好的。

@jeffvandyke我理解您的无奈并经历了同样的问题-但是，如果您在诺言之后有任何断言，您可能会喜欢此更改。

我有许多具有不稳定异步行为的规范。 根据我的规范的运行顺序，未捕获的承诺拒绝错误将记录到控制台，然后通过其他数百个通过的测试滚动到视线之外，否则节点实例将在拒绝发生之前关闭。

从我的mocha.opts删除--exit ，被拒绝的承诺将可靠地记录错误并突出显示这些错误。

我知道，很多共同的痛苦:) Mocha记录的行为对我来说似乎是正确的，但是即使我的5个测试看起来很简单，仅使用node-fetch来测试api，我仍然不确定为什么mocha不会退出，即使它们都成功通过了（是的，它们也可能失败）。 我可以花更多的时间来弄清楚为什么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从不关闭任何测试。

就我而言，我正在使用Koa应用程序，并使用Mocha 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要点起作用了： https :

wtfnode需要针对_mocha而不是mocha 。

感谢--exit 。 它为我解决了。

在package.json中输入以下脚本：
“脚本”：{
“ test”：“ mocha --exit”
}

我尝试了此线程中提到的各种补救措施：

• 为什么节点正在运行不产生任何输出
• wtfnode会产生输出，但不足以确定文件描述符/套接字/服务器/计时器在代码中的创建位置
• async_hooks调试方法错误
• 添加–exit到摩卡cmd行标志会导致退出

因此，按照@ProfJigsaw并使用–exit，这就是我正在做的。 但是，如果通过mocha进行改进，那将是很好的，至少是一种找出问题出在哪里以及如何解决这些问题的方法。

这就是IMO的调试器。 如果您的脚本从未退出，您将如何调试它们？

https://github.com/GoogleChromeLabs/ndb是一个很棒的项目。

题外话：我喜欢这张票，只是为了提供有关它不断提供的故障排除工具的信息！ :)

@borisovg想象一下，如果实际提供解决方案，这张票将有多大！ :)
@boneskull我不知道某些“列表文件描述符/套接字/服务器/计时器”调试器功能吗？

@mjgs对我wtfnode有效，但仅当我将其与_mocha二进制文件而不是与mocha一起使用时：

$ 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连接打开，但是my-shitty-code.js中的所有mongo连接都已关闭，因此问题出在其他地方，wtfnode没有提供足够的位置信息从。

如果wtfnode指示mongo数据库连接已打开，则表明它已打开。 您为什么会认为这是错误的？

@evert我认为您可能误解了我写的内容

最小的示例非常适合说明问题，实际上，看到与您看到的输出相似的输出很有用，但是在已经编写了多年的真实代码中，这些连接并不容易找到。 很高兴知道仍然有mongo连接处于打开状态，但是要真正找到它们并非易事。 我最终找到了一些开放的连接，但是它们在代码中比所有连接均已被可靠关闭的表面层次要深得多，wtfnode并没有通过列出猫鼬模块路径来帮助确定它们仅存在于何处。 我仍然有一些可以根据端口号进行跟踪，但是我很有希望。

我在编写与Firebase通信的无服务器功能时遇到了这个问题。 事实证明，他们的admin SDK会无限期维护打开句柄。 由于这种变化（以及随后的建议，使用的wtfnode ，我能够确定这一事实，并拯救自己一吨头痛（和成本）的下降之路。

在我看来，包含某种“如果它在X上挂了很长时间并且没有任何输出会向stdout抛出一些文本”的逻辑将非常有帮助。 我不确定这样做有多可行，或者有多少带宽可用于产生这样的改进，但是我认为这可能有助于减轻最初对“ wtf正在与我的摩卡咖啡打交道”的沮丧感。

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我喜欢此新行为有两个原因：

1. “完成工作”后，几乎没有其他图书馆会退出。 例如，关闭Node TCP服务器不会自动触发退出。 这样，它与其他库是一致的。
2. 如果节点没有退出，则意味着仍有事件等待解决。 最好尝试改进代码，以便在每次测试后都将其清理干净。 它还可能表明存在内存泄漏。

因此，当我遇到这种情况时，这是我尝试清理代码以免发生这种情况的诱因。

您对此的看法可能是“我不在乎内存泄漏”或“这不值得在我的应用程序中解决”。 如果您属于此类别，最简单的方法是制作mocha.opts并添加--exit 。

在我看来，这只是要发出更多的声音，而不是发出信号：在大多数情况下，没有人的应用程序会变得更好，因为Mocha最后挂了。

如果Mocha要默认使用，似乎应该默认在测试（以及所有after / afterEach调用）结束时结束。 仅仅告诉人们“嘿，您的人工测试环境是人工的”并不能使大多数（甚至是体面的少数）用户受益。

如果人们真的想调试未关闭的连接，则似乎应该是你提供一个选择的情况。 但是在所有其他时间中，图书馆的用户将其他所有人与“您处于测试环境中并且十亿种可能的事物之一处于开放状态”相混淆是否真的有益？

换句话说，如果您要告诉遇到此问题的99％的人“只使用--exit ”，那么也许--exit应该不是一个特殊的选择提供...也许默认的行为应该是服务于99％的用例（当然，仍然为用户提供--tell-me-if-I-have-unclosed-stuff-in-my-testing-environment-and-that-is-actually-what-i-am-trying-to-find-out的_option_）？

我的意思是，如果你所做的选择，现实你觉得多久人甚至会通过吗？

附言：我刚刚遇到了这个问题： https : 非测试代码（此“功能”使他们错误地认为需要在其应用中调用knex.destroy() ）。

摘要版本：

好的人：您可能通常不需要显式调用knex.destroy（）-这本身就是文档本身所暗示的（强调我的意思）：

好人：引文文档

困惑的人：如果我不调用knex.destroy（），我的脚本将挂起。 那么这意味着我们不需要显式调用knex.destroy（）

好人：啊，您在其他地方只提到这是给摩卡的。 对于常规的服务器使用，您不需要拆除连接池–对于Mocha，您可能希望查看全局的拆除挂钩，请参阅futurestud.io/tutorials/…

但需要明确的是，该用户具有工作环境，并且由于Mocha（本质上）告诉他们他们完美的代码是错误的，因此他们失去了谁，他们知道有多少时间试图通过破坏连接来解决他们所创建的错误。 而这仅仅是这一个倒霉的人谁正好做在公共，谁我碰巧看到。

所以，我想我要表达的是，这不只是关于什么是正确的哲学，也不是只是有些噪声掩盖有用信号......这种行为实际上造成伤害，并使程序员浪费时间倾斜在风车上。

对不起，我把您的累赘误认为是一个诚实的问题。 很遗憾回答。 也许开发人员可以锁定此线程。

"mocha --reporter mocha-allure-reporter ./tests/controllers --exit"为我工作。 实际上， --exit是一个很好的解决方法。 我在项目中使用版本5.2.0 。

有没有办法获得以编程方式使用mocha时使用--exit标志的等效效果？

我没有看到记录的退出/退出选项，也没有使用NodeJS API时传递标志字符串的一般方法。

按照其他选项的模式，我尝试了：

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/ " } ，它不起作用

有同样的问题，我想我不是唯一的一个。 我只需要移动-最后退出。
这不起作用：
伊斯坦布尔封面./node_modules/mocha/bin/_mocha --exit-test / .test.js这确实使我工作：伊斯坦布尔封面./node_modules/mocha/bin/_mocha-test / .test.js --exit

exit编程方式运行Mocha时，