まあ、ツールの助けを借りずにクロステストの依存関係を回避するのは非常に簡単です
to avoid cross-test dependencies without help of tooling
は簡単ですが、そのような依存関係を気付かずにテストスイートに追加することも簡単です。 テストスイートのバグは通常、テストされたシステムのバグに変換されます。 コードはおそらくテストでカバーされているため、これらのバグを追跡するのは困難です。
クロステストの依存関係がないかどうかのテストは、ツールなしでは不可能です。
@visionmedia 、再考してください。
+ 1 @ yanovich。 シード番号を出力するランダムオーダーオプションを使用します。 これは、CI環境で非常に役立ちます。
@visionmedia 、マングースモデルは、クロステストの依存関係の簡単な例を提供します。 mongoose.model 'User', UserSchema
は、モデルをmongoose.models
配列に追加します。 したがって、mongoose.modelsにロードされているユーザーモデルに依存するファイルを作成することが可能です。 例としてComment.find().populate('_user').exec(cb)
を取り上げます。 コメントテストの前にユーザーテストが実行された場合、おそらくrequire('./models/user')
(または何か)がユーザーモデルをmongoose.modelsにロードしているため、これは正常に実行されます。 ただし、ユーザーテストの前にコメントテストを実行すると、このエラーSchema hasn't been registered for model "User"
ます。 これは、コメントapiがユーザーapiの前に実行され、コメントファイルがファイル間の依存関係があることを認識していなかった場合に本番環境で発生する可能性があります。
テストファイルにrequire( './ models / user')(またはその他)があり、ユーザーをmongoose.modelsにロードする場合、テストが機能することで本番環境の問題が発生する可能性があります。 ただし、ランダムな順序を持つことは、このような潜在的な問題を発見するためのもう1つの便利なツールになります。
私はそれをうまく表現したいと思います。 あなたの考えを聞くのを楽しみにしています。
申し訳ありませんが、それは大きなやり過ぎだと思います。モカはそのままで十分に肥大化しています。 もっと興味があったら、おそらくメンテナンスの負担に値するでしょう。
考えてくれてありがとう。
コード内のほとんどのものと同様に、これを意図的に行うことを避けることを知っている人にとっては簡単です。 意図せずにそれを行うことを避けるのは難しいです。 そして、それが問題であることがわからない場合(つまり、混合経験チーム)、それはまったく起こりそうです:)
かなりの数のpplがそれに興味を持っているようです(そして多くの人がそれがミニテストの最高の機能の1つであると考えています)。 それがマージされれば、私は喜んで実装します。
+1興味がある。
持っていてよかったです! ファイル名の名前を変更すると、テストが失敗することがわかりました。
+1これは重要です
:+1:
:+1:
+1これはかなり大きな欠陥です。
rspecのセマンティクスはかなり堅実です。オーダーシードを渡すことも、ランダムに選択することもできます。 ランダムに種を選んだら印刷してくれるので再現しやすいです。
多くの場合、クロステストの依存関係を回避するのはそれほど簡単ではありません。 予期せぬグローバルな相互作用が原因の場合もあれば、都合が悪い場合もあります。 順序がランダム化された場合、mochaを使用するプロジェクトの50%以上でテストが失敗する可能性があります。 テスト実行の順序に依存しているように見えるいくつかの例を次に示します。
https://github.com/visionmedia/mocha/blob/master/test/hook.async.js#L95
https://github.com/visionmedia/superagent/blob/master/test/node/not-modified.js#L31
これら2つはhttp://visionmedia.github.io/mocha/に模範的なテストスイートとしてリストされており、問題を探すのにあまり時間をかけませんでした。
これを再開します。 役に立つと思います。 ツールなしでクロステストの深さを決定する方法はありますが、それを自動化できれば、人々の時間を節約できます。
これを少しいじった後、スイートの階層的な性質のために重要なように見えます。 テストは、スイートに再帰的に実行されます。 _Tests_をランダムに実行するには、それらを列挙し、ランダム化してから、逆方向に作業する必要があります。
これにより、 before()
フックとafter()
フックは、スイートの_n_テストごとに_n_回実行されるため、多少意味がなくなります(つまり、最悪の場合ですが、注意が必要な場合に限ります)。 )、コンテキストを継続的に変更します。 パフォーマンスが低下するようです。
ランダムシードを使用して自動生成されたシードを報告するのは簡単なようですが、レポーターはこの情報について知る必要がある場合があるため、レポーターに実装する必要があります。
もちろん、ここで説明したことは、求められていることだと思います。 このような機能には仕様が必要です。
その他のオプションには、「スイートのランダム化」または「スイート内のテストのランダム化」、あるいはその2つの組み合わせが含まれます。 実際には、これは、 describe()
ブロック_A_に入ると、_A_のすべてのテストが実行されるまで、親または兄弟のdescribe()
ブロック_B_でテストを実行できないことを意味します(これははるかに簡単な実装のように見え、 before()
/ after()
ひねりを引き起こすことはありません)。
私が求めているのは(そして他の人が求めていると思う)、最も単純なオプションです。
中級レベルで物事をシャッフルすることにはあまり価値がないと思います。
確かにハックですが、最低レベルで機能しますhttps://github.com/syrnick/mocha/compare/random_order?expand=1&w=0
mocha - fail
connect - pass
superagent - fail
express - pass**
websocket.io - pass (can't tell for sure)
**いずれにせよ、テストスイート全体の100回の実行で2つの断続的な障害が発生しました。
今後数日でそのコードをクリーンアップし、テストスイートを調整する予定です。 アンダースコアは、これに対する依存関係が重すぎますか? 私はおそらくこのような軽いものを使うことができます: http :
@boneskullこれを再開するというあなたの決定を支持します。 :+1:
その他のオプションには、「スイートのランダム化」または「スイート内のテストのランダム化」、あるいはその2つの組み合わせが含まれます。
私には十分すぎるようです。 完全に再帰し、列挙し、シャッフルする必要はありません。
これが起こっていると聞いてうれしいです。
rspecが再帰シャッフルを処理したのだろうか? 一見の価値があるかもしれません
彼らのコードで?
火曜日に、2014年8月26日、ジョシュアAppelman [email protected]
書きました:
@boneskullhttps ://github.com/boneskull私はあなたの決定を支持します
これを再度開きます。 [画像:: + 1:]その他のオプションには、「スイートのランダム化」または「テストのランダム化」が含まれます。
スイート」またはその2つの組み合わせ。私には十分すぎるようです。 ずっと下に戻る必要はありません、
列挙してシャッフルします。—
このメールに直接返信するか、GitHubで表示してください
https://github.com/visionmedia/mocha/issues/902#issuecomment-53482124 。
@syrnickこのような大きな依存関係を持つPRを受け入れたくはなく、代わりにseedrandom
ます。 それがなければ、シードをどのようにサポートするのかわかりません。 seedrandom
使用すると、シードを指定するかどうかを指定できます。指定しない場合は、シードが返されます。 次に、それをユーザーに表示し、RSpecで指定できるようにします。
@syrnickシードを生成した場合、レポーターに渡さないと「表示可能」にならない可能性があることに注意してください。 私はレポートアーキテクチャにあまり詳しくないので、確実に、または何をすべきかをあなたに伝えることができませんでした...
+1
私は実装を見ていませんが、デフォルトでランダムに順序付けられたテスト実行への+1が非常に重要です。
@syrnickよろしければ、これを行うつもりかどうか
喜んでそうしますが、すぐにETAを取得することはできません。
:+1:、あなたたちはまだPRの助けが必要ですか?
確かに、誰もこれに取り組み始めていないようです。
まず、フィッシャーイェーツシャッフルがここで仕事をするように見えます。
次に、3つの引数として--order random
、 --order random-suites
、および--order default
を使用し、オプションで:<seed>
ます。
+1。 テストがランダム化された場合、ずっと前に現れたであろうバグを見つけました。 RSpecがそれをサポートする方法と同様です。
ランダムなテスト順序の有用性を示すコードを次に示します。 より簡単な例がありますが、これはTDDデモ中に遭遇したものです。 テストの順序を逆にすると、最初のテストは常に失敗します。
game.js:
var express = require('express');
app = exports.app = express();
var sum = 0;
app.post('/bowl/:pins', function(req,res) {
var score = parseInt(req.params.pins);
console.log('Bowled ' + score);
sum += parseInt(req.params.pins);
});
app.get('/score', function(req,res) {
console.log('Sum: ' + sum);
res.send(sum + '');
});
app.listen(process.env.PORT || 3000);
test \ gameTest.js:
var request = require('supertest'),
should = require('should'),
game = require('../game.js').app;
describe('a game of bowling', function() {
describe('a gutter game', function() {
it('should score 0', function(done){
request(game).get('/score').expect(200, '0', done);
});
});
describe('a single pin game', function() {
it('should score 20', function(done){
for(var i = 0; i < 20; i++) {
request(game).post('/bowl/1').expect(200, done);
}
request(game).get('/score').expect(200, '20', done);
});
});
});
これが欲しいです。
:+1:
いくつかのグローバルを関与させ(これはJavascriptです、覚えておいてください)、サーバー呼び出しをスタブアウトし、テストでDOMから物を挿入/削除すると、順序依存性を追加するのは非常に簡単です。 テスト順序をランダム化すると、これらを後でではなく早く発見するのに役立ちます。
:+1:
:+1:
:+1:
+1
デフォルトでランダムな順序付けを行い、順序付けを再作成するためのオプションのシードを使用すると、優れた機能になります。
+1すると、ランダムな順序で実行するとテストが失敗することがあります...
それまでの間、UNIXを使用してください(残念ながら、ランダムシードはサポートされていません)。
mocha `ls -1 test/*.js | sort --random-sort `
モカがテストを実行する順序をグーグルで調べていて、これを見つけました。 ランダム化がない場合、デフォルトの実行順序は何ですか? テストがファイルに物理的に表示される順序は常にありますか?
:+1:
@danielabarええ、ファイルに表示される順序で並べられます。
@NicolasJacobええと、ランダムシードは実際にはある程度可能です。 :)
$ seq 10 | shuf --random-source=<(yes 2883)
1
7
3
4
6
2
10
5
9
8
https://github.com/bahmutov/rochaはこれで機能します。
@boneskullこれは古い問題ですが、 PR Please
ラベルはまだ有効ですか? もしそうなら、私は翌日かそこらで何か貢献を得るでしょう。
最終的にモカコアを最小限に抑えようとするために、チームは多くの新機能の導入に躊躇するかもしれないと思います。 mochaの次のメジャーリリースは、プラグ可能なインターフェイスを持つことを目標としています。
動作する場合は、 https://github.com/bahmutov/rochaを使用することをお勧めし
素晴らしい醤油
プラグ可能なインターフェースとはどういう意味ですか? このインターフェースを介してランダム化されたテスト順序を導入することは可能ですか?
機能リクエストの+1
@sulabhjain 、前と後のサポーターは、代わりに+1リアクションを使用してください。
このブランチの進捗状況。
この機能の+1
これは、テストを独立させておくためのテストフレームワークにとって実際に最も重要な機能の1つです。 すべての主要なJVMテストフレームワークには、この基本的な機能があります。
この機能の+1。 はい、十分な経験があるか、単独で作業することでテストの依存関係を回避するのは簡単ですが、常にそうであるとは限りません。
この機能に関心のある人は、ランダム化ブランチに対してPRを送信して、残っているものを完成させることができます。
機能の+1。 このためにブランチが進行中であることを本当に感謝します。
まだこれを待っています:))
これは本当に便利です。
@tjテストに関する基本的なスキルを持っている人と一緒に作業する場合、テストの依存関係を回避するのは簡単ですが、開発チームを引き継ぐ必要があり、テストケースに関する基本的な知識さえない人とぶつかることがあります。
実際、これは、既存のプロジェクトを引き継いで、1つのテストが前のテストに関連付けられているかどうかを簡単に確認したい場合にも役立ちます。
@boneskullお疲れ様でした! この修正のステータスはどうなっていますか? 何か助けが必要ですか?
モカテストをランダムな順序で実行するために使用する一時的なソリューションを共有したかっただけです。 多分それは誰かのために役立つでしょう。
mocha $(find tests/ -name *.spec.js | shuf)
残念ながら、それは同じ例の中でテスト例をシャッフルしませんが、それでもかなり賢くて便利です!
この機能をサポートする+1
これはまだテーブルにありますが、not-meからの注意が必要です
それで、実際にここに何が残っているのですか? どこから始めればいいですか?
それが実装されているのを見たいです❤️
choma
パッケージを見つけました。これは、Mochaがテストスイートとケースの順序をランダム化するための非常にシンプルなプラグインを提供します。 先に述べたロシャの良い代替品。 シンプルで問題を解決してくれます!
別の方法は、テストを並行して実行することです。
最も参考になるコメント
to avoid cross-test dependencies without help of tooling
は簡単ですが、そのような依存関係を気付かずにテストスイートに追加することも簡単です。 テストスイートのバグは通常、テストされたシステムのバグに変換されます。 コードはおそらくテストでカバーされているため、これらのバグを追跡するのは困難です。クロステストの依存関係がないかどうかのテストは、ツールなしでは不可能です。
@visionmedia 、再考してください。