まったく同じ問題が発生しています。 テストに合格すると、モカがハングします。 私のTravisCIを参照してください：
https://travis-ci.org/mkrufky/node-dvbtee/builds/282593109

また、video-dev /hls.jsでこれと同じ問題に気づきました-mochaはテストに合格した後にハングします：
https://travis-ci.org/video-dev/hls.js/builds/282590422

リリースノートを読みましたか？ https://boneskull.com/mocha-v4-nears-release/#mochawontforceexit

ありがとう。 モカのウェブサイトは、この重大な変更で更新されていません。 そこにあるCLI引数はそれについて言及していません。

迅速な修正（ --exit使用）を提供する以外に、欠陥のあるテストを見つけるという主要な問題をユーザーに任せたことに同意します。 今は自分で苦労していますが、メジャーバージョンをアップグレードするときは、やみくもにアップグレードするのではなく、リリースノートを必ず読んでください。

リリースノートでは、 https：//github.com/mafintosh/why-is-node-running/issues/7が原因で機能しない場合を除いて、 why-is-node-running使用を推奨してい

これもヒット。 デフォルトへの変更の背後にあるwhy-is-node-runningが放棄されて壊れていることを考えると、これは最もユーザーフレンドリーな変更ではない可能性があります。

こんにちは、みんな、

まず、この点で大まかなアップグレードパスについてお詫びしたいと思います。Mochaがテストの実行を維持しているものをユーザーに通知する必要があることに間違いなく同意します（そうすれば、プロセスを開いたままにする必要さえありません。それらが完了した後に失敗を返す理由です）が、まだ完全に満足のいく方法を見つけていません。 バージョン4は、PhantomJS 1.xのインストーラーの変更が原因でCIが失敗したためにプロンプ​​トが表示されたため、必要な時間を取得できませんでした（package-lock.jsonがあれば、おそらくこれを防ぐことができたでしょう）事前に設定しましたが、それでも動作させることができません）。 why-is-node-runningは、私たちが役立つとわかった1つのツール--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_modules/.bin/mocha代わりにnode --expose-internals ./node_modules/mocha/bin/_mocha実行することで使用できるノードオプションです。 Mochaが特定のフラグをノードに渡し、それらのフラグに--expose-internalsを追加できるため、これも修正できます。

ドキュメントとMochaのノードフラグの更新をそれぞれ追跡するために、mochajs / mochajs.github.io＃81と＃3045を作成しました。 少なくともドキュメントが更新されるまで、この問題は開いたままになります。

@ScottFreeCodeは、 --expose-internalsがノード<= 6でのみ機能することを伝えたいと思うかもしれません。うまくいけば、人々は一時的にノード6にダウングレードして、キャンセルまたは参照解除する必要のあるタイマー、または必要なソケットを見つけることができます。 unref'ed 。 また、人指すようにしたいかもしれafterとafterEachフックをクリーンアップを行うこと。

（すべてのテストが完了したときにmochaが呼び出すグローバルな「後」フックはありますか？）

とにかく、私は助けに感謝し、モカに感謝します！

--expose-internalsはノード<= 6でのみ機能することに注意してください。

本気ですか？ Node8.6.0でテストしました。 すべてのOSにあるわけではありませんが、持っているすべてのボックスを起動して、トリプルチェックする必要があると思います...

これは、当面の間回避するための

本気ですか？ Node8.6.0でテストしました。 すべてのOSにあるわけではありませんが、持っているすべてのボックスを起動して、トリプルチェックする必要があると思います...

これは、モジュールからの出力をトリガーするという点で「機能」しますが、Node.jsのバージョンに関係なく、実際には多くの情報を提供しません。

サイトにいくつかの更新を追加しますが、＃3045に関する今後のコメントを参照してください。

これは、モジュールからの出力をトリガーするという点で「機能」しますが、Node.jsのバージョンに関係なく、実際には多くの情報を提供しません。

setTimeoutとsetImmediate便利なスタックトレースを提供しますが、リスニングサーバーなどの他のものについては実際の情報はまったくありません（最近、サーバーがどのように機能しているかを理解しようとしたときにわかりましたやっています）。 要旨の「async-dump」の例は、新しいバージョンのNodeでのみ使用可能ですが、すべてに対して機能する（ --expose-internals必要としない）という点で真の利点があります。

私の一般的なアドバイスは、「髪を抜く場合は、 --exitを追加してリラックスする」というものだと思います。 次に、次のプロジェクトには使用しないでください：wink：

...そしてここにドキュメントがあり

クローズドPRについて再度コメントして申し訳ありませんが、ここにユーザーフレンドリーな解決策があるかもしれません：

ランナーが3秒ほど終了した後、変更された動作に関する警告をログに記録できますが、プロセスは終了しませんでした。
ランナーが終了した後にsetTimeout()を追加し、 timeout.unref（）を呼び出して、このタイムアウトによってプロセスの終了が妨げられないようにする必要があります。 タイムアウトが実行された場合は、警告の時間です😉

私はそれを考慮しましたが、それがレポーターや他の統合で他の問題を引き起こすのではないかと心配しています...私はそれが起こらないことを証明することはできません。

それでも問題が発生し、 why-is-node-runningが正しく機能しない場合は、 wtfnodeを確認して

そのパッケージは私にとってはるかにうまく機能しました。

既存のテストが突然終了しなくなると、（控えめに言っても）戸惑うことがあります。 リリースノートに新しい動作についての言及があり

私は、after（）関数でredis.quit（）を呼び出すことを強制する新しいテストで偶然に変更を発見しました。私は、正しくて適切と思われる新しい動作に間違いなく満足しています。

今回は[この要点]を使用する必要はありませんでしたが、 @ boneskullですでに述べたように、どの非同期タスクが完了しておらず、プロセスの終了を

この新しい動作の変更の背後にある参照チケットの問題を完全には理解していないことを認めなければなりません。

AFAICT、それは未処理のPromise拒否と関係があります。 しかし、ごめんなさい。モカのテストに与えられた約束を解決しないと、モカは成功せず、そのテストから続行しません（ --bailが設定されている場合）。 したがって、拒否ハンドラーを持たない、実装が不十分なネストされたPromiseである必要がありますが、含まれているコードはとにかく解決されている必要があります。

この場合、これらの問題を検出するのがモカの仕事であるかどうかはわかりません。 また、これらの問題を検出するために何らかの魔法を実装すると、現在の（正しく記述された）テストが無期限にハングする可能性がある場合、その魔法はオプトアウトではなくオプトインの動作である必要があります。つまり、 --no-exitではなく--exit 。

公式のnode-mongodb-nativeドライバーを使用してすべてのテストを調べてい.close()ですべてを閉じないため、設計上のようです。 私のテストは正しく動作していますが、依存関係は正しく動作していません（または、そうではありませんか？スクリプトが他の場所で終了するまで、ソケットまたはファイル記述子が長引くのは悪い動作であるという事実を必ずしも知りません—そうですか？）。 それで、私はここで何をテストしていますか？ 私のコード、または他の誰かのコード？ 私は自分でテストしていると思っていましたが、明らかにそうではありませんでした。

確かに、 --exitフラグを追加することはできますが、次の人は追加できない可能性があります。いずれにしても、完全に細かいコードをテストして完全に細かいテストを記述でき、それでもランダムな依存関係の原因があるのは間違っているようです。私のテストは無期限にハングします。

最後のafter()フックにprocess.exit()を追加すると、テストはハングしませんが、 --watch （おそらく他の機能）だけでなく、ひどく壊れます。変更を監視できなくなりますが、カーソルのないシェルに排出されます。

私がここで無知な人である可能性が非常に高いです（確かに私が得ていないことがたくさんあり、多くの人々が関わっているので、私はそう思う傾向があります:)）、私はちょうどこの全体のように感じます物事は完全ではありません...そうです...？

乾杯:)

編集：この動作を考えると、Mochaテスト内で--watchで実行されているかどうかを確認して、 process.exit()を呼び出さないようにし、問題を解決する方法はありますか？

@DanielSmedegaardBuus TL; DR on the solution： --exitをmocha.optsファイルに入れます。 （これは通常、より一般的なヒントとして、Mochaの実行時に常に設定する必要があるすべてのソリューションです。）この変更の詳細については、以下を参照してください。

2640は、promiseの拒否に関するものであり、何もすることを意図したものではなく、promise以外の非同期テストコードからスローされる同期例外と一致させることを目的としており、

これは、Promiseが実装やテストで使用されているかどうかに関係なく、リソース、リスナー、または進行中の作業をセットアップし、クリーンアップしないテストに関するものです。 例えば：

接続の開始と終了を含む、WebSocketに基づくAPIのテストがあります。 このAPIはバグがあり、接続を正しく閉じていませんでしたが、基礎となる接続が正しく処理されたことをテストに断言する方法が実際にはなかったため、テストに合格しました。 （自分のコードのみを厳密にテストした場合、誤って正しい方法であると誤って考えた方法で依存関係を使用していることを確認できました。ただし、最初に使用法の正確性に関する問題をキャッチするために、実際のWebSocketで正確にテストしていました-単体テストを補完する統合テスト。） --no-exit動作（Mocha3の;現在はMocha4のデフォルト）に切り替えたときにそのエラーをキャッチし、これらのテストを実行するとノードが閉じないことを発見しました。 WebSocket接続はまだリッスンしています。

（エラーが独自のコードではなく依存関係にある可能性があるのは事実ですが、それでも、その依存関係の特定のバージョンを出荷する前に、上記で示唆したように、これはそもそも単体テストよりも統合テストに適していますが、理想的にはプロジェクトに両方が含まれています。）

もちろん、これは必ずしも必要ではありません。場合によっては、この性質のリソースは、プロセスが強制終了されるまで存続することを意味する場合や、リソースの他のクリーンアップが実際には重要でなくてもノードを存続させる場合があります。個々のメンバーを再利用するリソースプールの一部である可能性があり、プール全体をクリーンアップする必要はありません。そのような場合、 --exitが正しいでしょう。 デフォルトの動作が変更された理由は、そのような問題の可視性を高めるためでした。以前は、 --no-exitを試してこれらの種類のエラーをチェックすることを知らなかったでしょうが、デフォルトでそれらに遭遇します動作が正しい（または少なくとも心配する価値がないと判断した場合）場合は--exitます。

もちろん、これが発生したときにぶら下がっているがあります。 サポートされているすべてのバージョンのNodeで機能し、まだ実行されている可能性のあるものに干渉することなく、実行中のものを実際にプログラムでチェックする方法を統合できるかどうかをまだ理解する必要があります（適切な警告またはエラーを表示できます）。モカが終わりに達したときにクリーンアップまたはクローズします。

申し訳ありませんが、これは非常に苛立たしいことでした。 モカが出ない理由を調べようとしていたところです。 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私はあなたの欲求不満を理解し、同じ問題を経験しました-しかし、約束の背後にある主張がある場合は、この変更に感謝するかもしれません。

非同期動作が不安定な仕様がいくつかありました。 仕様の実行順序によっては、キャッチされなかったプロミス拒否エラーがコンソールに記録され、合格した他の何百ものテストによって見えなくなるか、拒否が発生する前にノードインスタンスがシャットダウンします。

除去した後、 --exit私からmocha.opts 、拒否された約束が確実にエラーを記録し、それらのバグを強調表示します。

私は知っています、多くの共通の痛み:)モカの文書化された動作は実際には私には正しいように聞こえますが、私の5つのテストは十分に単純に見えますが、ノードフェッチを使用してAPIをテストするだけですが、モカが終了しない理由はまだわかりません、それらはすべて正常に合格しますが（はい、失敗する可能性もあります）。 why-is-node-runningが機能しない理由を理解するためにもっと時間を費やすことができましたが、他の人のコードについてうんざりしているので、とりあえず休憩するつもりです。

私はおそらくそれで遊んでいくでしょう、そして私が再現可能な何かを得ることができれば、私は新しい問題を開くかもしれません、しかし約束はありません。

新しいノードインスペクターのデバッガーをお勧めします...それは良い非同期トレースを持っています。

わーい！ wtfnodeは、これに光を当てるのにはるかに優れていることがresult.text()または.json()を呼び出す必要があることがわかりました。そうしないと、接続が開いたままになります。 wtfnode ./node_modules/.bin/_mochaを実行し、 Ctrl-Cを押すと、開いている接続が表示されました。

ドキュメントがwhy-is-node-runningよりもこのパッケージを推奨していればもっと簡単だったと思います。

別の提案：モカが終了しない場合に何らかの警告を出すというです。 モカがwtfnode使用して、しばらく経過した後もノードを存続させているアクティブなハンドルを一覧表示できれば便利です。

正しいことが何であれ、モカが出ない理由を理解するためにここまで見なければならなかったのはゴミだと思います。 とにかく、私は私の提案をしました:)

こんにちは、みんな、
私は、これは私が考える可能性があり、モカはまだ自分自身で終了するには失敗した最も基本的なテストでは、この機能はまだ正常に動作していないかもしれないと思います。 --no-exitは優れたデフォルトのオプションであり、私はそれですべてですが、私が間違っていることを理解できていないか、mochaに本質的に何かが間違っており、最も単純なテストでさえ閉じることができません。

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

それがsomenoeに役立つことを願っています。

私はすべてのテストの前にモカのブートストラップを行っています。 基本的に、同じプロセスで小さなHTTPサーバーを起動します。

モカの実行が停止した後、フックしてシャットダウンできるイベントはありますか？ シャットダウンしたいのですが、その時だけです。

この機能の背後にあるアイデアが大好きです。ぶら下がっているイベントがあるかどうかを確認するための良いテストです。

@evert afterサーバーを閉じても機能しませんか？

モカが行われた後に実行されるグローバルな「すべての後」はありますか？ 私はそれを逃したかもしれません！ ドキュメントで見つかりませんでした。

はい、グローバルafterフックがあります。

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

ありがとうございました！ 私はそれを逃しました、申し訳ありません：/ ctrl-fの用語を知りませんでした。

wtfnodeは私にとって実際には機能しませんでした。 私が見ることができたのは、モカによって開始されたいくつかのPIDがぶら下がっていたということだけでした。

一方、 @ boneskullの要点は機能しました： https ：//github.com/mochajs/mocha/issues/3044#issuecomment-351299745。 ありがとうございました！

wtfnodeは、 mochaではなく、 _mochaに対して実行する必要があります。

--exitありがとう。 それは私のためにそれを修正しました。

このスクリプトをpackage.jsonに入力します。
「スクリプト」：{
"test"： "mocha --exit"
}

私はこのスレッドで言及されているさまざまな救済策を試しました：

• why-is-node-runningは出力を生成しません
• wtfnodeは出力を生成しますが、ファイル記述子/ソケット/サーバー/タイマーがコード内のどこに作成されているかを判別するには不十分です
• async_hooksデバッグメソッドエラー
• –exitをmocha cmd lineフラグに追加すると、exitになります

したがって、 @ ProfJigsawをフォローし、

それがデバッガーの目的です、IMO。 スクリプトが終了しなかった場合、どのようにデバッグしますか？

https://github.com/GoogleChromeLabs/ndbはクールなプロジェクトです。

オフトピック：私はこのチケットが大好きです。それが提供し続けるトラブルシューティングツールに関する情報のためだけです！ :)

@borisovg実際に解決策を提供した場合、このチケットがどれほど素晴らしいか想像してみてください。 :)
@boneskull私が

@mjgsそれは私のために行いました- wtfnodeは機能しましたが、 _mochaバイナリではなく、 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がmongodb接続が開いていることを示している場合、それは開いています。 なぜあなたはそれが間違っていると思いますか？

@evertあなたは私が書いたものを誤解したかもしれないと思う

最小限の例は説明に最適であり、実際には、表示されているものと同様の出力を確認するのに役立ちますが、長年にわたって作成された実際のコードでは、これらの接続を見つけるのはそれほど簡単ではありません。 まだ開いているmongo接続があることを知っておくのは良いことですが、実際にそれらを見つけることは簡単ではありません。 私は最終的にいくつかの開いている接続を見つけましたが、それらはすべての接続が検証可能に閉じられた表面レベルよりもコード内ではるかに深く、wtfnodeはマングースモジュールパスをリストすることによってそれらが存在しただけの場所を特定するのに役立ちませんでした。 ポート番号だけに基づいて追跡するものがまだいくつかありますが、期待しています。

Firebaseと通信するサーバーレス関数を作成するときにこの問題が発生しました。 管理SDKがオープンハンドルを無期限に維持していることが判明しました。 この変更（およびその後のwtfnode使用の提案）により、私はその事実を特定し、将来の頭痛（およびコスト）を大幅に節約することができました。

私の意見では、ある種の「Xが長くハングし、出力がない場合は、テキストをstdoutにスローする」ロジックを含めると非常に役立ちます。 それがどれほど実現可能か、またはそのような改善を生み出すためにどれだけの帯域幅が利用できるかはわかりませんが、それは「wtfが私のモカで起こっている」という最初の欲求不満を和らげるのに役立つかもしれないと思います。

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

timers.restore();を忘れると、プロセスは永久にハングします。

ここに送信された@pgiladのドキュメントに基づいて、私にはよりクリーンなソリューションがあります。 ドキュメントが言うように：

誤検知を回避し、より良いテストプラクティスを促進するために、Mochaは、実行を実行する必要があると判断したときに、process.exit（）を介して自動的に自殺することはなくなりました。

よりクリーンな解決策は、グローバルafter関数（ describe関数の外側にあるafter ）を作成することです。 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. 「作業が完了した」後、他のライブラリはほとんど終了しません。 たとえば、ノードTCPサーバーを閉じても、自動的に終了はトリガーされません。 このように、他のライブラリと一貫性があります。
2. ノードが終了しない場合は、解決を待っているイベントがまだあることを意味します。 各テストの後に物事がクリーンアップされるように、コードを改善してみることをお勧めします。 また、メモリリークがあることを示唆している可能性もあります。

したがって、これに遭遇したとき、これは、コードをクリーンアップして、それが起こらないようにするためのインセンティブです。

これについてのあなたの見方は、「私はメモリリークを気にしない」、または「これは私のアプリケーションで修正する価値がない」かもしれません。 あなたがこのカテゴリにしている場合は最も簡単に作ることですmocha.optsおよび追加--exit 。

これは信号ではなく、より多くのノイズを発生させることであるように私には思えます。ほとんどの場合、モカが最後にハングしたため、誰のアプリも良くなることはありません。

Mochaがデフォルトになる場合は、テスト（およびすべてのafter / afterEach呼び出し）が終了したときにデフォルトで終了する必要があるようです。 「人工テスト環境は人工的だ」と人々に伝えるためだけにそうしないことは、大多数のユーザー（またはまともな少数派）に利益をもたらしません。

人々は本当に閉じていない接続をデバッグしたい場合は、それはあなたがのためのオプションを提供する場合でなければなりませんようです。 しかし、それ以外の時間は、ライブラリのユーザーが他のすべての人を「テスト環境にいて、10億もの可能性のあるものの1つが開いている」と混乱させることは本当に有益ですか？

別の言い方をすれば、これに遭遇した人の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_を提供します）？

つまり、あなたが

PS私はちょうどこれに出くわしました： https ： 非テストコード（この「機能」により、アプリでknex.destroy()を呼び出す必要があると誤って考えられました）。

要約バージョン：

ナイスパーソン：通常、明示的にknex.destroy（）を呼び出す必要はありません。これは、ドキュメント自体が（私の強調）と言っていることによって暗示されています。

ナイスパーソン：引用ドキュメント

混乱している人：knex.destroy（）を呼び出さないと、スクリプトがハングします。 では、knex.destroy（）を明示的に呼び出す必要がないというのはどういう意味ですか

ナイスパーソン：ああ、これはモカのためだと他の場所でだけ言った。 通常のサーバーの使用では、接続プールを破棄する必要はありません。Mochaの場合は、グローバルな破棄フックを調べることをお勧めします。futurestud.io/ tutorials /…を参照してください。

しかし、明確にするために、このユーザーには作業環境があり、モカは（本質的に）完全に良いコードが間違っていると言ったため、接続を破壊することによって作成したバグを解決しようとする時間を誰が知っているかを失いました。 そして、それは公共の場でそれを行うために起こった、と私は見ることが起こった人だけで、この1不運な人です。

だから、私が伝えようとしているのは、これは哲学的に正しいことだけではなく、いくつかのノイズが有用な信号を覆い隠しているということでもありません...この動作は実際に害を引き起こし、プログラマーに時間を浪費させています風車で。

すみません、あなたの疲れた点を正直な質問と間違えました。 答えて後悔しています。 たぶん、開発者はこのスレッドをロックすることができます。

"mocha --reporter mocha-allure-reporter ./tests/controllers --exit"は私のために働いた。 実際、 --exitは非常に優れた回避策です。 プロジェクトではバージョン5.2.0を使用しています。

「プログラムで」mochaを使用するときに--exitフラグを使用するのと同等の効果を得る方法はありますか？

exit / noexitの文書化されたオプションも、NodeJSAPIの使用中にフラグ文字列を渡す一般的な方法も表示されません。

他のオプションのパターンに従って、私は試しました：

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これは私を動かしました：istanbul cover ./node_modules/mocha/bin/_mocha --test / .test.js --exit

exitは、プログラムでMochaを実行しているときは何もしません、fwiw。 プロセスは、Mocha-the-libraryではなく、CLIラッパーによって強制的に終了されます。