1つはテスト用、もう1つはテスト用の2つの並列ディレクトリを作成する方がよいでしょう。
データファイル用。 それが私がしたことです。
午前04.03.201515：52schrieb「KylePDavis」 [email protected] ：

除外パターンを提供できるようにしたいと思います
テストファイルのパターンに一致するテストファイルのみ。 これにより、データが許可されます
妥当なものに従う限り、テストファイルと共存するファイル
パターン。

これは単に無視オプションを設定するオプションを提供することだと思います
グロブで。

考え？ よろしければ、すぐにPRできます。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/mochajs/mocha/issues/1577。

私はできました（そして過去にそうしました）が、glob ignoreがすぐそこにあることに気付いたので、もうそうする必要はありません。

コマンドライン引数を追加してglobignoreオプションを設定するのは非常に簡単です。 最初に考えて少し話し合いたかっただけです。

このためのPRを作成することに異議はありますか？

私もこれが必要だったのですが、モカがまだ持っていなかったのでびっくりしました。 それは素晴らしい追加になると思います。 テストフォルダ内に「testApp」があり、テスト専用に使用しています。 mochaがそのフォルダー内でテストを実行しようとしないようにします。 他のすべてのテストサブフォルダーを明示的に含めるのではなく、mocha.optsファイルにexcludeを追加して、その特定のパスを除外できると便利です。

testAppを移動することはできますが、実際にはリポジトリ内の他の場所には収まらず、テストフォルダー内の特定のファイルへの相対パスを取得します。

これは素晴らしい追加になると思います。 確かに重要ではありませんが、役に立ちます。

@KylePDavis @toddbluhm

これが必要な場合は、おそらく

$ mocha $(find test/ ! -path '*testApp*')

ですから、私はそのアイデアにそれほど興奮していません。 シェルコマンドMakefile 、 Gruntfile.js 、 gulpfile.jsでも同じことが達成できるので、 recursiveフラグの存在についても少し気になります。 gulpfile.jsなど。

@boneskullは良い点だと思います-これはすでにさまざまな方法で達成可能です。 そして、これを完全に回避するためにディレクトリを構造化できるという事実は含まれていません。 たとえば、この構造が与えられた場合：

$ tree .
.
└── spec
    ├── fixtures
    ├── integration
    └── unit

4 directories, 0 files

package.jsonを更新するだけで、 npm test実行できます。

  "scripts": {
    "test": "mocha spec/unit spec/integration"
  }

または、次のような構造になります。

$ tree .
.
└── src
    └── models
        ├── user.js
        └── userSpec.js

2 directories, 2 files

@boneskullの例と同様の方法で仕様を実行できます（これはSpecを含むファイルのみを実行します）

  "scripts": {
    "test": "mocha $(find src -name '*Spec.js')"
  }

編集：修正:)

@danielstjules名前にSpecれているdirに実際にヒットすると思います。 おそらくあなたは-name '*.spec.js'が欲しいでしょう

うん、そうだね！ Brainfart。 それを指摘してくれてありがとう。

例の修正されたコマンド：

  "scripts": {
    "test": "mocha $(find src -name '*Spec.js')"
  }

この機能の有効な使用例はまだあると思います。ファイルを機能ごとにグループ化する傾向があるため、各テストファイルは、テストしているロジックを含むファイルの隣にあります。 テストファイルの命名は、 file引数またはgrepオプションで一貫して機能しますが、 node_modulesようなものは明示的に無視したいと思います。

探している人のために-gulp-mochaはこれを達成することができます、私は私がする必要がないところにgulpを含めるのが嫌いです。

少し時間を取って、このアイデアを+1したいと思います。 通常のJavaScriptプロジェクトとは異なり、私はGOが単体テストを行う方法に従うのが好きで、テストされるすべてのファイルの横にスペックファイルを含めます。 たとえば、私のプロジェクトの1つのディレクトリは次のようになります。

main.js
main.spec.js
utilities.js
utilities.spec.js

このタイプの組織では、テストファイルの単一のディレクトリを掘り下げるよりもテストを見つけるのがはるかに簡単であることがわかりました。 テストは、テストするファイルのすぐ隣にあり、ビルドスクリプトはデプロイされたバージョンのすべての.spec.jsファイルをスクリプト化することを常に期待しています。

私の非標準のレイアウトのために、私がやりたいのは、node_modulesディレクトリを除くすべてのフォルダですべての単体テストを実行することです。

現在、近くにWindowsボックスはありませんが、その検索構文がWindowsで機能するかどうかはわかりません。 私の意見では、除外オプションの方がはるかに直感的です。 さらに、ほとんどすべての単体テストフレームワークには、とにかくファイルを無視する方法が含まれているため、パリティがあれば便利です。

こんにちは、私のすべてのテストは*.test.js形式をサポートしています。 それらはすべてtestsディレクトリにあります。 現在、除外したいテストがいくつかありますが、mochaのデフォルトパスである./test/**/*.js保持しています。 それ、どうやったら出来るの？

ここでは、2つの別々のディレクトリを作成することはできません。また、ディレクトリ間でテストを移動すると、VCSで多くのノイズが発生することに同意する必要があります。

@calebthebrewerありがたいことに、私はプロジェクトで

+1 @calebthebrewer

Angular 2.0とPolymerではコンポーネントモードになっているので、@ KrisSiegelに同意します。 すべてのコードをバンドルに保つことで、クリーンでモジュール式の、保守が容易なファイル階層が維持されます。

次のような方法でq promiseライブラリを使用してテストをロードする際に予測できる問題はありますか。

import q from 'q';

import authRouterTest from '../app/routes/_authentication.router.e2e.js';

import productRouterTest from '../app/routes/_product.router.e2e.js';

import productModelTest from '../app/models/product.model.spec.js';

// Dynamically constructed sequence of functions
let funcs = [ productModelTest(), authRouterTest(), productRouterTest() ];

// This function takes an array of promise-producing functions and
// runs them sequentially.
let execTests = () => {

    let result = q();

    funcs.forEach((f) => {

        result = result.then(f);
    });

    return result;
};

// Execute tests
execTests();

このようにして、どこからでもファイルをインポートし、 test/ 1つのテストファイルを置くことができます。

最後のテストブロック内でpromiseを解決し、各テストを次のようにまとめることができます

import q from 'q'

export default () => {

    let Q = q.defer();

    describe('something', () => {

        it('should', (done) => {

            ...
        });
    });

    describe('something', () => {

        it('should', (done) => {

            ...
        });

        it('should', (done) => {

            ...

            Q.resolve('test complete');
        });
    });

    return Q.promise;
};

私が考えていないことがない限り、それはかなりうまくいくようです。

まだグロブを無視する必要があります。 bashコマンドの使用は、クロスプラットフォームソリューションではありません。

+1

本当にnode_modulesを除外したいと思います。 Exclusionは、 recursive非常に便利なコンパニオンのようです。

@godspeedelbowなぜその特定のディレクトリを明示的に無視する必要があるのでしょうか？ 通常、 node_modulesがテストディレクトリにあるという話は聞きません。

FWIW、私もこれを本当に使うことができました。 テストがライブラリ自体よりもはるかに大きいプロジェクトがいくつかあります。これにより、テストをより適切に整理できるようになります（フィクスチャはテストディレクトリIMHOに属します）。

node_modulesを無視することは、予期しないことをしているとき（私がテストするファイルの隣にスペックファイルを保持するのではなく、テストするコードから離れて単一のフォルダーに保持するような場合）に重要になりますメインプロジェクトとそれに含まれるいくつかのプロジェクト（おそらく、テストしたいnpmリポジトリではなく、内部ライブラリです）に対して単体テストを実行しますが、独自の依存関係内で単体テストを実行したくない場合。

この問題はもう1年近く続いているので、実装されることはあまり期待できません。 私の意見では、回避策にはプラットフォーム固有のターミナルコマンドが必要であるか、テストするディレクトリごとにパターンを明示的に指定するため、実装することが重要です（したがって、テストスクリプトにディレクトリを追加する必要があります）。 私はそれをフォークして自分でやるだけですが、各ディレクトリとパターンを指定するハッキーな方法を使用する方が、モカに実装する時間を見つけるよりも簡単です。

@KrisSiegelいつでもsrc/**/*.jsとsrc/**/*.spec.jsます。 GoプロジェクトとRustプロジェクトでは、プロジェクトルートから開始するよりも頻繁に見られます。 実際のところ、後者は比較的まれです。

彼らは誰かが自分でそれをするのに時間をかけるのを待っているだけだと思いますが。 作成するのが難しいパッチのようには見えません（ロジックがスパゲッティコードステートマシンの混乱でない限り）。

私は実際に自分自身のテストフレームワークに取り組んでいるので、個人的にこれを行うように駆り立てられていません。モカ、ジャスミン、テープなどの完全な代替となることを目的としていますが、コアはよりシンプルで強力です。 とはいえ、おもちゃプロジェクトのATMでさえ、まだ進行中の作業が多すぎます。

私はMochaを使用して、フレームワークを効果的にブートストラップしています。 アサーションが安定するまで、最初はChaiを使用していました（フレームワークのアサーションを使用してテストしているため、現在は実質的にAPIロックされています）。

ええ、それは回避策です。スペックとソースファイルのペアリングについても同じことが言えますが、そのように構造化されたJavaScriptプロジェクトはあまり見られません。 私は基本的にそのパターンを使用しますが、独自のカスタムビルドシステムですでにかなり大きなプロジェクトに参加する場合、それを変更するのは必ずしも簡単ではありません。

Excludeは、多くのユーティリティが持っているかなり基本的なパターンです。 モカにはそれが必要だと思います:)。 私の印象ではありますが、この問題はプラットフォーム固有の回避策に基づいてクローズされたため、パッチを待つのではなく、望ましくないという印象でした。 これがモカの人々が実際に望んでいるものであるなら、それが数週間以内に行われなければ、私は確かにパッチをクランクアウトすることができます。

@KrisSiegel誰かが実際にパッチをクランクアウトした場合、直感的でない特別な構文や追加のフラグが含まれていない限り、パッチはおそらくマージされると確信しています。 FWIW、_this_のPRはまだありません。プラットフォームに依存することを考えると、この問題が解決された理由はかなり弱かったです。 そして、いくつかのテストを実行するためだけにGNU findをインストールすることをいとわないWindowsユーザーはあまり見かけません。

クローズされる可能性がありますが、ノードの実装はわずかに逸脱しますが、同様の状況がクローズされた問題、進行中のPR ）。

それが価値があるもののために+1。 私が作成したプロジェクトには、 appまたはsrcフォルダーは必要ありませんが、代わりに、さまざまなインターフェイス実装を持つさまざまな量の名前付きフォルダーがあります。 また、インターフェイスごとにテストをバンドルしたままにし、テストに1つのフォルダーを使用するように強制されないようにします。

.mochaignoreまたは他のオプションで無視するファイルを指定できることが理想的です。そうすれば、 **/*.spec.jsグロブで実行でき、 node_modulesからのテストが含まれる可能性があることを心配する必要がありません。

他のほとんどすべてのビルドツールでこれが可能です。 .npmignore 、 .gitignore 、 .jshintignoreがあり、jscsには.jscsrc介して構成するオプションがあります。 靴下の引き出しのアプローチから離れて、コンポーネント/機能ファイルとフォルダーの編成に向かって移動する人が増えているので、モカもそれをサポートするのであれば便利です。

@isiahmeadowsは、他の人が言及したように、簡単に変更できないフォルダー構造で立ち往生しているため、 services/ 、 routes/などがnode_modules同じようにプロジェクトのルートにあります。 node_modulesを除外するための3番目のツール（コマンドライン、gulp、またはその他のもの）が必要です。

どこから始めればよいかわかっていれば、自分でモカに実装したいと思います:)

@ godspeedelbow @ adambuczynski一時的な解決策:)

  "scripts": {
    "test": "mocha $(find . -name '*.spec.js' ! -ipath '*node_modules*')"
  }

こんにちは@danielstjulesありがとう！ 試してみましたが、何らかの理由でfind . -name '*.spec.js' ! -ipath '*node_modules*'はテストファイルを1つしか見つけません。

テストが従うパターンに合うように'*.spec.js'を更新しましたか？ たとえば、_all_ jsファイルを照合するには、次を使用します。

  "scripts": {
    "test": "mocha $(find . -name '*.js' ! -ipath '*node_modules*')"
  }

@danielstjulesは歓声を上げますが、それは私が信じているWindowsでは機能しません。このアプリでは問題ありませんが、私はそれを入れるのをためらっています。

それまでの間、アプリのコードとテストをappサブフォルダーに移動して、そのフォルダーをテストの対象にし、 node_modulesやその他のフォルダーについて心配する必要がないようにしました。

@danielstjulesええ、すべてのテストファイルは*.spec.js形式です。 何らかの理由で以前は機能しませんでしたが、問題なく機能するようになりました。 この* NIX回避策をありがとう。

これが次のメジャーのために行われるのを見たいです。 特に.mochaignoreサポートすることは私には合理的だと思います

@boneskullありがとう、それは素晴らしいことです。

次のメジャーリリースでは、 mocha.optsを使用するのではなく、プロジェクトのルートに配置できるオプションを渡すためのより「標準的な」 .mocharc実装も検討しますか。 testフォルダにありますか？

これにより、Mochaの構成がはるかに簡単になり、他のツールで行われる方法と一致します。 さらに、 mocha.optsためだけにtestフォルダを用意する必要はありません。 （すべてのテストを、テストするモジュールと並べて配置します）。

@adambuczynski絶対に。 私はmocha.optsのファンではありません

@adambuczynski素晴らしいコメント。 同意します。標準の.mocharcオプションファイルも必要です。コードの横にテストを保持するのはとても良いので、テストディレクトリも使用しなくなりました。

+1、除外が本当に必要だと思います。

@adambuczynski @boneskullドキュメントには、例は示されていませんが、 --optsを使用してoptsファイルへのパスを指定できることが示されています。 私は現在のプロジェクトでこれを使用しており、 mocha --opts .mocharcとして機能することを確認できます

@GRUBESに感謝します。 結局、テストセットアップヘルパーもそこに配置するので、 testフォルダーを使い続けましたが、それが可能であることを知っておくとよいでしょう。

Globには無視オプションがあるので、除外オプションを追加してglobignoreに転送するだけでも大したことではありません。

無視一致を除外するには、パターンまたはglobパターンの配列を追加します。 注：無視パターンは、他の設定に関係なく、常にdot：trueモードです。

なぜこれに1年以上かかるのかわかりません。 :-)

@ inf3rnoところで、誰かが実際に座ってパッチを書いていれば、これはおそらくずっと早く解決されたでしょう。

@isiahmeadowsええ、でもそれは私ではありません。 ：D

それで、これはまだPRが必要ですか？ testとtest-integrationの複数のディレクトリではなく、テストファイルのコロケーションを使用したいので、これを追加できれば幸いです。

2036は、基本的に同じ一般的な種類のものであり、コマンドラインオプションではなくファイルのみであり、PR＃2173があります。

--excludeようなオプションを追加するといいかもしれません。

またはmocha test/*.js !test/_*.jsようなものをサポートします

考え出したグロブ： mocha "./{,!(node_modules)/**/}*.test.js"はnode_modulesを除くすべての* .test.jsファイルを取得し、 mocha "./test/**/!(notThisOne).js" notThisOne.jsを除くテストフォルダーとサブフォルダー内のすべてを取得します

参照：
https://github.com/isaacs/node-glob#glob -primer
https://github.com/isaacs/node-glob/issues/62

@ScottFreeCode

ターミナルで実行すると、

mocha "./{,!(node_modules)/**/}*.test.js"
-bash: !: event not found

このキャラクターはエスケープする必要がありますか？

@mdumouchel一重引用符を使用します。 そうでなければ、そうです。

@isiahmeadows

まだエラーが発生しています

node_modules/mocha/lib/utils.js:630
        throw new Error("cannot resolve path (or pattern) '" + path + "'");
              ^
Error: cannot resolve path (or pattern) './{,!(node_modules)/**/}*.test.js'

結局、findコマンドを使用するだけでした

mocha $(find . -type d -name node_modules -prune -o -name '*.test.js')

@mdumouchelバージョン2.x（つまり、npmにあるもの）を使用している場合は、とにかく機能しません。 サポートは3.x、IIRCで開始されます。

それは奇妙なことです。Bashで試してみて、二重引用符を使用できたと思いました。 WindowsとBashの両方で機能する構文/エスケープを知っている人はいますか？

また、「パスを解決できません」というエラーは、パスがプロジェクト内のどのファイルとも一致しないことを意味していると確信しています。 私が与えたパスは、対応するソースファイルの横に「.test.js」で終わる名前のテストファイルがある場合、テストから問題のコメントにコピーするのを台無しにしない限り、現在のバージョンで機能しました...

＃2173を参照

Eslintは、 --ignore-path （および.eslintignore ）のファイルを無視して素晴らしい仕事をします。
参照： http： //eslint.org/docs/user-guide/command-line-interface#ignoring -files

モカに似たものは素晴らしいでしょう：two_hearts：

私の回避策：

eslint "test/!(fixtures)/**/*.js" "test/*.js"

私のファイル構造

.
└── src
└── test
    └── fixtures
        └── data.js
    ├── foo.js
    └── bar.js

問題：2つのパスのいずれかが何かと一致しない場合、モカは私にError: cannot resolve path (or pattern)を与えます。

OK、それで私は容赦します。 これはユーザーフレンドリーではありません。

これは私たちがすべきだと思うことです：

1. --exclude <glob-or-path>サポート
2. --exclude _複数_インスタンスをサポートする
3. すべての--excludeオプションとすべての非オプション引数を1つのリストに結合します（基本的には
4. それらのファイルをロードします

現在、_n_非オプション引数をサポートしています。これはすべてグロブである可能性がありますが、これは_additive_のみです。 これはあなたが期待するようには機能しません：

$ mocha 'src/**/*.spec.js' '!src/forbidden/**/*.spec.js'

したがって、上記は機能するはずであり、 --excludeは実際には!単なる砂糖です。

さらに、 .mochaignore （＃2036）のサポートは良さそうに聞こえますが、別の問題です。 .gitignoreような動作をするためにプルできる3pモジュールがあるはずです。 ESLintが行っていることは、私たちの目的には十分であると確信しています。

...明確でない場合は、コマンドラインで引用符で囲まれていないグロブを使用しないでください。 ＃2355を参照

驚いたことに、 --ignore-pathようなオプションはまだありません。すべてのテストをtestsフォルダーに入れる以外に、モジュールと一緒にテストを置くことができない理由はありません。

+1
パターンでファイルやディレクトリを無視することは非常に便利な機能です

@isiahmeadows

いつでもsrc / /.js

いいえ、できませんでした- **/*パターンマッチングが壊れており、再帰的に機能しません。

編集： @ScottFreeCodeには以下の答えがあります

**/*パターンマッチングは壊れており、再帰的に機能しません。

あなたの道は引用されていますか？

+1

https://github.com/zinserjan/mocha-webpack/issues/124で説明されているように：

src/中には、エクスプレスサーバーを起動し、バックグラウンドで実行されるserver.tsというファイルがあります。 通常、カバレッジの実行中はサーバーが稼働しているため、ポートはすでに使用されています。

したがって、これは望ましくなく、このファイルのみが除外されます。

http://remarkablemark.org/blog/2017/02/07/mocha-glob-pattern/

モカは無視する必要があるという私の意見を表明します。なぜなら、この間ずっと、メンテナはまだ説得力を必要としているからです。

モカはカノンです。 他のすべてのテストフレームワークが目指しているテストフレームワークのクロスプラットフォーム機能セットの水準を上げてみませんか？ すべてをBashに任せることを熱望するのをやめるべきです。 その2017年はすでに。

また、Windowsの人々はBashの!(glob) （実際にはBash主義であり、POSIX標準でさえありません）に相当するものを持っていないことも指摘しておきます。

Mochaのglobingは、Glob JSモジュールを介して処理されるため、そのままではBashの依存関係はありません。 （注：パスを引用は例えば、どのようモカは希望とは異なるシェル処理グロブを回避するために必要な場合があります** globstar拡張子なしまたは何でもそれはそれますが、その特別なものです。）

@ScottFreeCodeglobを使用するときにextglob: trueを使用しますか？ その場合は、回避策としてその構文でこれを閉じることができます（glob / minimatchはそのオプションを有効にしてサポートしているため）。

globへのパスを渡しているようです。 ある時点でグロブパターンを介して否定が機能することは間違いありませんが、それはモジュールの古いバージョンであった可能性がありますか？ いずれにせよ、私たちは二重星の振る舞いのテストを行っているので、誰かがテストを提出していくつかの否定パターンも機能することを確認したい場合（または誰かがすでに持っているグロビングテストに欠陥を見つけた場合）、それは素晴らしいことです。

ただし、明示的なignore / excludeオプションを使用することには明確な利点があります。 実際には、複数の利点があります。

• あいまいさが少ない
• さまざまなOSの特殊文字や引用規則との衝突を回避しやすく
• 多くの場合、包含リストから除外リストを引いたものは、否定された部分を持つ包含リストよりも単純です

現状が特定のシェルに依存することを意図していないことを明確にしたかっただけです。 ; ^）

多くの場合、包含リストから除外リストを引いたものは、否定された部分を持つ包含リストよりも単純です

本当です、そして私はそれについてほとんど忘れていました😄

この問題に来る人：

回避策は、これがサポートされているはずなので、グロブを使用することです。 誰かがこの特定の行動を望んでいるなら、PRを送ってください。

--excludeオプションは機能しますか？
ドキュメントで見つかりません。

@ sepo-oneドキュメントを更新するためにPRを開きました。
mocha -h利用可能なすべてのオプションを確認できます。

ええ、私は古いバージョンのモカを使っています。 アップグレードされ、 --excludeオプションがあります。
とにかくドキュメントを更新する必要があると思います。

ありがとう@outsideris