Mocha: グローバルのオプトアウト

require('mocha')ときに、そのがらくたをグローバルスペース全体にダンプしたとしても、現在の状態よりも優れています。

ばかげているとは思いませんが、すべてとのトレードオフがあります。 私はこのようなものに満足しているでしょう：

var Mocha = require('mocha');
var mocha = new Mocha(options);
mocha.describe('blah blah', function....

誰もそれを使用しませんが、少なくとも私たちが現在持っているものを実装するためのよりクリーンな方法になるでしょう。 誰もが毎回セットアップしなければならない定型文が_トン_ありますが、それらをCLI風のAPIに絞り込むことができれば、問題ありません。 ARGVで渡されたばかりのlib / cli.jsがあったとしても、誰もがそれを使用するかどうかは疑わしいですが、CLIがなくてもかなり簡単に使用できますが、それは、一部のエッジケースを超えて本当に望んでいる人がいないことを示しています。

@visionmediaそれはかなりいいようです。 私がrequire("mocha/bdd")などを提案した理由は、既存のモカに関しては実装が非常に簡単だからですが、ええ、おそらくあなたの方が良いでしょう。 （たとえば、一度に複数のテストスイートを実行するために使用することを想像できます。まあ、process.on（ 'uncaughtException'）の使用のためにおそらく壊れますが、私が何を意味するかはわかります。）

いつかプルリクエストを試すかもしれません。

これは、代入を破棄することによる少し将来のJavaScriptが大いに役立つ素晴らしい例です。
https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/1.7#Destructuring_assignment_％28Merge_into_own_page.2Fsection％29

var [describe,it,beforeEach,afterEach] = new require("mocha")(options);

これに対するノードハーモニーのサポートがあればいいのにと思います。

これができるという考えですか

node test/a-mocha-test.js

そして、それはそのテストを実行しましたか？

@glenjamin yup

nodespecで自分でこれを実行しようとしましたが、問題は実際にはさまざまな関数を使用可能にすることではなく、実行を開始する方法とタイミングを把握することでした。2パスの定義/実行アプローチが必要です。

私が思いついたオプションは次のとおりです。
1）すべてのユーザーにmocha.exec（）のようなものをすべてのファイルの最後に追加してもらいます。
2）コアがprocess.on（ 'exit'）のようなものを追加するのを待ちますが、イベントループがまだ利用可能な場合
3）各フ​​ァイルにトップレベルのdescribeブロックが1つしかないことを想定し、それが終了すると実行を開始します

（1）はおそらく最も優れており、次のようになります。

var run = require('mocha/required');

describe('blah blah' , function() {
// ..
});

run();

mochaラッパーなしで実行する必要がある場合、これはnode ./node_modules/.bin/_mocha test/a-mocha-test.jsを実行するよりも多くを追加するようには見えません。

これは、モカが現在使用されている方法とはもはや一致しないと思います。 このスレッドは1年以上非アクティブになっているため、今は閉じています。

それでも誰かがこれに興味を持っている場合は、コメントするか、プルリクエストを提案してください。検討します:)

これを再開できますか？ まだまだ興味があります。 node test.jsモカテストだけができないことが、私とMapboxの同僚がモカからテープやタップなどのハーネスに移行した主な理由の1つでした。 個人的にはモカに固執したいのですが、「ノード能力」の議論はやや説得力があります。

編集：「node-ability」引数は@tmcwによってここで詳しく説明されました。

明確にするために、 requireインターフェイスがないことは、ユーザーの観点からはここでの主要なブロッカーではありません。 以下は、動作するようにすでに文書化されています。

var describe = require('mocha').describe;
var before = require('mocha').before;
var it = require('mocha').it;

そしてそれはES6でより良くなります：

import { describe, before, it } from 'mocha';

問題は、これがmochaバイナリを介して実行されている場合にのみ機能するという事実です。

ああ、説明してくれてありがとう。 :) mochaバイナリを使用して実行したときにすでにこの機能を提供している場合は、ノードでも同じことを行うとよいと思います。 それを調べます。 ありがとう！

ノードにbeforeExitフックがあるので、これはかなり実行可能のようです。

次のようなものである必要があります

var { describe, it } = require('mocha/auto')

ええ。 TJが言ったように、問題は、すべてを「ノード対応」にしたとしても、有用であるためにはボイラープレートが多すぎる可能性があることです。

しかしながら...

@glenjamin beforeExitのヘッズアップに感謝します。 これを活用できると思います。 人々はおそらくそれがあまりにも多くの「魔法」だと不平を言うでしょう...

3cdd4a04c48193cceac6af7db72af06d380014a9に概念実証を追加しました

とにかく、少し手間がかかりますが、すべてのインターフェースで簡単に一般化できると思います。 ここでは、Growl、 mocha.optsまたは終了コードなどの他のさまざまなprocess関連のものはサポートされていません。 bin/_mochaからいくつかのコードを抽出し、ここで再利用する必要があります。 次に、引数のサポートもあります。 例えば：

$ node test/my-test.js --reporter=dot

誰かが何か提案があれば、lemmeは知っています

bin/_mochaにあるもののいくつかをある種のCLIに抽出することは、関係なくかなり賢明だと思います。

これが本当に便利な追加かどうかはまだわかりませんが？

次のいずれかに実際的な違いはありますか？

node test/test.js
./node_modules/.bin/mocha test/test.js
PATH=./node_modules/.bin:$PATH mocha test/test.js
npm test -- test/test.js

nodeテストファイルを実行できないためにモカを使用していない人は、単にモカが嫌いで言い訳を探している人だと感じます。 モカは皆のためである必要はありません：smile：

こっちも一緒。 jspmとSystemJSを使用していますが、ブラウザーで実行されているテストでMochaをimportできません。

import { describe, before, it } from 'mocha';

ブラウザで使用する場合は使用できません。

@glenjaminそれはちょっと起こる必要があります。 MochaにはコアプログラマティックAPIが必要です。 その良い副作用は、ノード可能なテストです。 それが実行される環境は、それがブラウザ、CLI、またはその他のものであるかどうかにかかわらず、プログラムAPIを消費します。 Mocha.app、誰か？ :)

この機能に興味があります！

+1の場合：
import { describe, before, it } from 'mocha';

現在const {describe, it} = require('mocha')がありますが、グローバルはすでに存在するため、必要ありません。

ブラウザのサポートに関心がある場合は、いつでもconst {describe, it} = window.mocha実行できます。 私たちはすでにチャイのためにこれをしなければなりません。

まあ、 const {describe, it} = windowもそうだと思います。

これはmochaのアーキテクチャにとって非常に基本的なものであるため、mochaはバンドル時に

mochaは、単一の名前空間以外のグローバルを定義するべきではないと思います。おそらくブラウザ専用です。

mocha実行可能ファイルは引き続きグローバルを使用します。 それはおそらく変わらないでしょう。

私たちが狙うことができる（そしてすべきである）のは、グローバル名前空間を汚染することなく、 nodeを介してモカテストを簡単に実行する機能です。 それがこの問題の目的です。

残念ながら、それはテキサスサイズのより糸のボールであり、誰も解き明かす時間やエネルギーを持っていませんでした。これはこの問題の時代から明らかになるはずです...

mocha実行可能ファイルは引き続きグローバルを使用します。 それはおそらく変わらないでしょう。

モカがどのように構成されているかについては何も知りませんが、この単一の設計の選択が問題の原因であると断言できます。

おそらくそうです！

私は実際にコードをもう一度見て、前回グローバル変数をハックしようとしたときに何が間違っていたかを理解し、 node test/someFile.jsでテストファイルを実行可能にするために何が必要かを考えました

• グローバルを回避する
  
  
  
  • セムバーメジャーでも、グローバルを使用するモカの使用の圧倒的多数を破ることはできません。 チームは全員、日常の仕事を辞め、二度と眠ることはなく、残りのキャリアをそれに費やすことができましたが、それでも文字通り、想像を絶する大量のサポート要求を処理するのに十分な工数がありませんでした。 したがって、これは永遠に旗の後ろにあります。
  
  
  • 現在、BDDおよびTDDインターフェースは特殊なケースです。どちらもrequire("mocha").itとしてエクスポートされます（他のインターフェースはエクスポートされません）。 （注：他のインターフェースが選択されたときにこれが壊れない理由は、Mochaにバグがあり、ほとんどの場合、別のインターフェースが選択されていてもBDDインターフェースをセットアップするためです。＃2207）これから離れたいと思います。
  
  
  • カスタム（サードパーティ）インターフェイスは、エクスポートスキームで機能する必要があります（ globalをハードコーディングする代わりに、発行されたコンテキストオブジェクトを使用する場合）。
  
  
  • Mocha （ require("mocha")エクスポートするもの）にその関数を追加するすべての可能なインターフェイスを持つことはできません。
  
  
  • BDDインターフェースが常に設定されているバグを修正した場合、別のインターフェースが選択されたMocha BDDおよびTDDインターフェースをエクスポートし続けるのは難しいでしょう。
  
  
  • require("mocha/tddInterface").testまたはrequire("mocha/interface/bdd").itを実行しない限り、MochaのUIをTDDに設定してBDDインターフェイスを使用したり、その逆を行ったりしないでください（ "mocha/lib/interfaces/<interface name>"と混同しないでください）。実装はライブです）。
  
  
  • semver-majorまで、下位互換性のためにexport-BDD-and-TDD-on-Mocha-if-possibleの動作を維持することができます。 それを要求して使用している人々は彼らが何をしているかについてもっとよく知っていて、とにかくそれによって完全に満足していないので、私たちがそれを落とすときに多くの人々が不平を言うことはないと思います（グローバルはまだそこにあります）。
  
  
• ノード機能、つまりmocha test/someFile.js代わりにnode test/someFile.jsを実行できる
  
  
  
  • グローバルよりもユビキタスではありませんが、 var Mocha = require("mocha"); var mocha = new Mocha()など（つまり「プログラムインターフェイス」）を使用している人々を壊す余裕はないと思います。 それを検出してMochaの「ノード対応の方法」を実行しないようにするか、（私たちにとっては簡単ですが、ユーザーからのオプトインが必要です）別のインポートを介してノード機能にアクセスする必要があります（例： require("mocha/nodeable").it （ .describeなど）。 代わりにピギーバックの特別輸入require("mocha")安全に実施するために容易になるだろうと私の願望で収まるように（説明と回避グローバルセクションに正当化）のインターフェイスを輸出から脱却するためにMochaオブジェクトrequire("mocha")によってエクスポートされます。
  
  
  • node test/someFile.jsを実行するには、 someFile.jsがMochaのインターフェイスをインポートできるだけでは不十分です。Mochaをインスタンス化する必要があり、テストがすべてセットアップされた後、Mochaを実行する必要があります。 つまり、 require("mocha/nodeable")は、インターフェイスをエクスポートするだけでなく、Mochaをインスタンス化する必要があります。次に、テストファイルの実行後にMochaを実行する必要があります。
  
  
  • これを行う1つの方法は、テストファイルが非同期アクションを開始しない場合、 process.on("beforeExit"でMochaを実行することです。
  
  
  • これを行う別の方法は、Mochaをprocess.nextTickまたはsetImmediateまたはsetTimeout(..., 0 /* or some small number */)です。
  
  
  • --delayを使用して設定し、 run()を使用して非同期で実行するテストは問題になります。 いつ実行するかを知るためではなく、より簡単で、 run()あります。また、 --delay （以下を参照、またはrequire("mocha/nodeable/delayed")提供する）を実行するかどうかを知るためでもありません。 run()は、現在設計されている1つのテストファイルでのみ呼び出されることになっています。 おそらく、その設計はすでに扱いにくいので、とにかくすべてのテストファイルでrun()が呼び出されるように修正する必要があります。その場合、「ノード対応」テストで使用するのは簡単です。それを修正します。 そうでなければ...私は何をすべきかわからない。
  
  
  • nodeではなくmochaを介してこれらのテストファイルを呼び出せるようにしたい場合（つまり、これを使用してもnode使用は強制されません）、 requireは何でも
  
  
  • Nodeを実行するとき、 mocha.optsを使用するとき、またはノード対応のテストファイルがMochaのデフォルト以外の動作を使用できるようにするものを使用するときに、Mochaフラグの受け渡しをサポートする場合は、CLIピースをよりモジュール化する必要があります。動作。
  
  
• これらの2つのアイデアの制約を組み合わせて、私は提案します（そして実装できると信じています） ：
  
  
  
  • グローバルを回避する
  
  
  • 関数を配置するためのglobalオブジェクトをインターフェイスに渡す代わりに、「選択されたインターフェイスオブジェクト」を渡します。 （追加するために編集：これはlib/mocha.jsとbrowser-entry.js両方で実行する必要があります。私が知る限り、提案のすべてのグローバル関連部分はノードとブラウザーの両方で実行可能です。 ）
  
  
  • その後、選択したインターフェイスオブジェクトのすべてのコンテンツをglobalコピーします。
  
  
  • localInterfaceオプション（CLIでは--local-interface ）は、Mochaが選択したインターフェイスオブジェクトからglobalコピーするのを停止します。
  
  
  • DEBATABLE：最初は、 require("mocha").itとの下位互換性のために、Mochaは選択したインターフェイスオブジェクトからMochaにもTDD / BDD関数をコピーしますが、これは後で非推奨/削除されます。
    
    
    
    
    
    • （注：選択されていないときにBDDのセットアップを停止する場合、これらをコピーできるダミーの選択されたインターフェイスオブジェクトにBDDをセットアップするために、ここでさらに特別な処理を行う必要がある場合があります-ドロップするのに適したケースです動作全体としては、これをサポートしようとしている間に修正/改善する他の事項が増えるほど、複雑になります。）
    
    
    
  
  
  • require("mocha/interface")は、選択したインターフェイスオブジェクトをエクスポートします。
  
  
  • require("mocha/interface/<specific interface>")は、新しく選択されたインターフェイスオブジェクトを使用して指定されたインターフェイスを呼び出し、後でエクスポートします。
  
  
  • 追加のために編集： require("mocha/interface")は、ブラウザのmochaオブジェクトmocha.interfaceプロパティにもなり、モジュールシステムなしでのブラウザの使用をサポートします。
  
  
  • ノード能力
  
  
  • require("mocha/nodeable/<specific interface>")は、Mochaをインスタンス化し、テストファイルの後に実行するようにMochaを設定します（ delayが使用されていない限り、おそらくsetTimeout使用します。上記のdelay ）。 require("mocha/interface/<specific interface>")ように、そのインターフェイス用に選択したインターフェイスオブジェクトをエクスポートします
  
  
  • CLIオプションまたはmocha.optsがサポートされている場合、 require("mocha/nodeable")はMochaをインスタンス化し、テストファイルの後に実行するようにMochaをセットアップし（上記を参照）、CLIと同じインターフェイスセットアップ手順を実行して、 require("mocha/interface")ように選択されたインターフェイスオブジェクト。
  
  
  • ノード対応のテストファイルもmocha対応にしたい場合は、 mocha/nodeableとmocha/nodeable/<specific interface>は必要ありません。ノード対応をmocha/interface便乗させることができます。 mocha/interface/<specific interface> 。
  
  

考え？

実際、さらに考えて、 mocha <test file>代わりにnode <test file>を使用しないという次の理由で、このチケットを閉じるように動議します。

• 私はそれが提供する利点を知りません。
  
  
  
  • 考えられるアイデアの1つは、 mocha.optsグロブに関係なく、単一のテストファイルのみを実行することです。 簡単な解決策：代わりにpackage.jsonのtestスクリプトにグロブを配置します： npm testはそれらすべてを実行し、 mocha （ node_modules/.bin/mocha 、 npx mocha ）は、指定されたテストファイルのみを実行します。 （実行されるテストファイルの数に関係なく、任意のテスト実行で実行する必要があるファイルまたはグロブは、引き続きmocha.optsます。）
  
  
  • もう1つの考えられるアイデアは、 mocha.opts完全にバイパスできるようにすることです。 これは、 mocha --opts /dev/null （またはWindowsではmocha --opts nul ）を使用して実現できるはずです。 何らかの理由でそうでない場合は、CLIフラグを実装してmocha.opts処理をスキップする方が簡単です。
  
  
• モカの外で実装できます。 "mocha/nodeable"代わりに、MochaのプログラマティックAPIを使用して同じコードを架空のパッケージ"nodeable-mocha"入れるだけです。
  
  
  
  • そもそも実装が簡単だと言っているのではなく、モカの外にいるために実装が難しくなる可能性があることを私は知らないと言っています。
  
  

コアの外部よりもコアで達成しやすい重要な利点を発見した場合は、いつでも再開できます。

ただし、次の理由から、回避グローバルチケットを再開することも求めています。

• 利点が関連する可能性は低いですが（ describe 、 itなどの名前のグローバルを使用している他のライブラリはいくつありますか？）、原則として可能です（その質問への回答はもっと大きい可能性があります） 0よりも小さいですが、少数です）-グローバル名前空間にデータをダンプしないことは、理論的には正しいことです。
  
  
  
  • さらに、私の計画では、グローバルオブジェクトをハードコーディングするのではなく、発行された「コンテキスト」オブジェクト（現在Mochaは常にグローバルオブジェクトを使用）を使用するように正しく記述されたサードパーティインターフェイスに同じ動作を拡張します。 私たち自身のインターフェースが他のライブラリーに干渉する可能性は
  
  
• 私の計画では、現在の動作に関連する多くのエッジケースをクリーンアップします（たとえば、サードパーティのインターフェイスに拡張するだけでなく、BDDおよびTDDインターフェイスを特別なケースにする代わりにMochaの一貫性もクリーンアップします）。
• Mochaの外部でそれを実装する唯一の簡単な方法は、MochaのプログラマティックAPIを使用してモンキーパッチを適用することです。これにより、前述の不整合やエッジケースの一部も残ります。

つまり、Mochaがmochaを使用してテストを実行する方法を提供しているが、 global汚染しないフラグの背後にあることを示唆していますか？

モカモカを作る理由の一部とその成功の一部は、ものをインポートするために定型文を必要としないことです。 グローバル名前空間を汚染することに関する教義にもかかわらず、開発者の人間工学のためにそうする完全に正当な理由があります。

つまり、モカはモカを使用してテストを実行する方法を提供しますが、グローバルを汚染しないフラグの背後にあることを示唆していますか？

うん。

モカモカを作る理由の一部とその成功の一部は、ものをインポートするために定型文を必要としないことです。 グローバル名前空間を汚染することに関する教義にもかかわらず、開発者の人間工学のためにそうする完全に正当な理由があります。

私は一般的に同意しないと言っているわけではありませんが、オプトイン機能として、一部の開発者がグローバルではなくインポートを必要とする可能性がある場所を確認できます（おそらく、誤って参照せずにモジュールにローカル変数context必要があります）彼らがvarを忘れた場合、グローバルに、おそらくその種の衝突がさらに起こりやすいサードパーティのインターフェースを使用したいと思うでしょう）、そして今私はそれを正しく行う方法を理解しましたアドオンいくつかの並べ替えのようによりモカで行うことも簡単に（私は他の何かに吸い込ま取得しない場合、実際には、私はおそらく証明するために今週のブランチでラフ案を一緒にスローされます）。

（さらに、インターフェイスがグローバルに設定された後、 Mochaオブジェクトにコピーされるので、 require("mocha").itができるように、私たちはすでにちょっとした試みを一貫性がなく、バグが発生しやすく、実際にはグローバル名前空間の汚染を回避することすらできません。そのような機能を維持する場合は、疑わしいバージョンを維持するのではなく、修正することもでき

これはIMOであり、Mochaテストでnode <test file>を実行できるのとは対照的です。これは、私が知る限り、利点がなく、Mochaの内外で同様に実装するのが難しいでしょう。

@stevenvachon
const {describe, it} = require('mocha')が機能しないのはなぜですか？ 未定義になりました...

$ node -v
v8.4.0

@zapphyreあなたはまだ介してテストスイートを実行する必要がありますmochaません経由で、プログラムnode 。

nodeで複数のソースファイルを実行することはできないため、 mochaスタックします。 独自の実行可能ファイルを持たないテストランナー/フレームワークを知りません。

より具体的に問題のタイトルを更新しました

これの別の理由： low.jsなどの別のJSランタイムを使用してテストを実行したいと思います（これはプラットフォームの1つであるため、他はnode.js、ブラウザー、およびReact Nativeです）。 モカをインポートしてテストを実行するJSファイルがある場合はそれを実行できますが、テストを実行するためにmochaを呼び出す必要がある場合は実行できません。

つまり、あなたはすでにブラウザのためにそれをしているのです。 そのプラットフォームには、「mocha」をインポートし、 mocha.run()を使用してグローバルmochaオブジェクトからテストを実行するJSコードがあります。

ブラウザで私は

• モカをロードして、グローバルmochaオブジェクトを取得します
• mocha.setup({ui: 'bdd'});実行します
• SystemJSを使用してすべてのテストファイルをロードします
• それから私は走ります

      mocha.checkLeaks();
      mocha.globals([]);
      mocha.run();

以上です。 node.jsで同じことを試し、SystemJSの代わりにrequireステートメントを使用してテストファイルをロードすると、次のようになります（mocha 5.2.0を使用）

> mocha.run();
TypeError: Cannot read property 'search' of undefined
    at Mocha.mocha.run (/home/mha/one/node_modules/mocha/mocha.js:149:54)

編集： https ： mocha.addFileをロードするだけでなく、同じ結果を試しました。

現在、describe / itをインポートする方法はありますか？

新しい（現在20時間前の）Wikiページhttps://github.com/mochajs/mocha/wiki/Using-mocha-programmaticallyがあり実行するためのものです。

これの別の理由： low.jsなどの別のJSランタイムを使用してテストを実行したいと思います（これはプラットフォームの1つであるため、他はnode.js、ブラウザー、およびReact Nativeです）。 モカをインポートしてテストを実行するJSファイルがある場合はそれを実行できますが、テストを実行するためにmochaを呼び出す必要がある場合は実行できません。

代替ランタイムにノードのような実行可能ファイルがある場合（low.jsにはあると思いますか？）、 alternative-executable ./node_modules/.bin/_mocha実行でき、それは機能するはずです。

独自の実行可能ファイルを持たないテストランナー/フレームワークを知りません。

https://github.com/tapjs/node-tap/#tutti -i-gusti-sono-gusti

https://github.com/mochajs/mocha/issues/3006が解決されたので、ブラウザーに同じ名前のエクスポートがあると便利です。

現在、以下が機能しています。

<script type="module">
  import './node_modules/mocha/mocha.js'
  console.log(mocha)
</script>

しかし、以下はそうではありません：

<script type="module">
  import { mocha } from './node_modules/mocha/mocha.js'
  console.log(mocha)
</script>

（https://github.com/mochajs/mocha/issues/956#issuecomment-167453800によって要求されたとおり）

これは、ブランチをロールアップとマージしてトランスパイラーをセットアップすると簡単になる可能性があります。 esmバンドルと、esmコードパスを消費してグローバルリークを追加するレガシーバンドルを用意することは可能と思われます。 ブラウザとノードの両方で壊れたりコードを記述したりしないように、新しく追加されたコードパスとバンドルのみを変更するように細心の注意を払う必要があります。

グローバル変数とタイピングを使用すると、これはモカをレガシーなものにします。

ところで、グローバルなしで@types/mochaを作成しました： https ：

それら（グローバル）がまもなく正式に削除されることを願っています。