ユニットテストにはどれくらい遅いですか？
Michael Feathers、レガシーコードを効果的に使用する、13〜14ページに次のように記載されています。
実行に1/10秒かかるユニットテストは遅いユニットテストです... [ユニットテスト]が速く実行されない場合、それらはユニットテストではありません。
30,000のテストがある場合、実行に1時間近くかかるため、1/10秒が遅すぎる理由を理解できます。しかし、これは1/11秒の方が良いという意味ですか？いいえ、そうではありません（わずか5分速いため）。したがって、ハードファストルールはおそらく完璧ではありません。
したがって、単体テストには遅すぎることを考えるとき、おそらく質問を言い換える必要があります。 開発者が単体テストスイートの完了を待つにはどれくらいの時間がかかりますか？
テスト速度の例を挙げます。いくつかのMSTestユニットテスト期間のタイミングを見てください。
0.2637638 seconds
0.0589954
0.0272193
0.0209824
0.0199389
0.0088322
0.0033815
0.0028137
0.0027601
0.0008775
0.0008171
0.0007351
0.0007147
0.0005898
0.0004937
0.0004624
0.00045
0.0004397
0.0004385
0.0004376
0.0003329
これらの21の単体テストすべての平均は0.019785秒になります。最も遅いテストは、MicrosoftMolesを使用してファイルシステムをモック/分離するためであることに注意してください。
したがって、この例では、ユニットテストスイートが10,000テストに増えた場合、実行に3分以上かかる可能性があります。
私は、ユニットテストの数によってシステムがすべてをテストするのに時間がかかりすぎるようなプロジェクトを1つ見ました。 「長すぎる」とは、基本的に通常の開発ルーチンの一部としてそれを行わなかったことを意味します。
しかし、彼らが行ったことは、単体テストを2つの部分に分類することでした。重要なテスト、および「その他すべて」。
重要なテストの実行には数秒しかかからず、システムの最も重要な部分のみをテストしました。ここでの「重要」とは、「ここで何か問題が発生した場合、すべてが問題になる」ことを意味します。
実行全体に時間がかかりすぎるテストは、「その他すべて」セクションに追いやられ、ビルドサーバーでのみ実行されました。
誰かがソース管理リポジトリにコードをコミットするたびに、重要なテストが最初に再度実行され、数分後に「フルラン」がスケジュールされました。その間隔の間に誰もコードをチェックインしなかった場合、完全なテストが実行されました。確かに、彼らは30分もかからず、8-10のようでした。
これはTeamCityを使用して行われたため、1つのビルドエージェントが完全な単体テストスーツで忙しい場合でも、他のビルドエージェントは通常のコミットを取得し、必要に応じて重要な単体テストを実行できます。
私はこれまで、テストスイートが取ったプロジェクトにのみ取り組んだことがあります 少なくとも 実行するのに10分。大きいものは、より時間のようでした。そして、私たちはそれを吸い上げて待っていました。なぜなら、彼らはあなたが彼らに投げたものの中で少なくとも1つの問題を見つけることがほぼ保証されていたからです。プロジェクトはとても大きくて毛深いものでした。
数秒で包括的にテストできるこれらのプロジェクトが何であるかを知りたいです。
（プロジェクトの単体テストに数時間かかる場合に物事を成し遂げる秘訣は、同時に4つまたは5つの作業を行うことです。テストスイートで1セットのパッチをスローし、タスクを切り替えます。切り替えたものが終わったら、結果が戻ってきたかもしれません。）
まず、UNITテストとINTEGRATIONテストの違いに関するZackの回答に対する私のコメントを参照してください。
次に、ファイルをチェックインするたびに（テストライブラリ全体ではなく）コード変更の影響を受けるテストのみを実行するMight-Moose（Mighty-Mooseは廃止されましたが、他のツールもあります）などのツールを使用します。
実行に数秒かかる単体テストがあります。 非常に複雑なコンピューティングと数十億の操作を実行するメソッドがあります。このトリッキーで超高速な方法をリファクタリングするときに、ユニットテストの基礎として使用するいくつかの既知の良い値があります（私が言ったように、それはそれからがらくたを最適化する必要があります必須何十億もの計算を実行しています）。
ルールはすべてのドメイン/問題空間に適応するわけではありません。
このメソッドを単体テストできる小さなメソッドに「分割」することはできません。これは小さいですが非常に複雑なメソッドです（その場で十分な速度で再作成できない非常に巨大な事前計算済みテーブルを利用するなど）。 。
その方法の単体テストがあります。それらはユニットテストです。実行には数秒かかります。グッドシング[TM]です。
もちろん、ユニットテストではないものにJUnitのようなユニットテストライブラリを使用していることに異論はありません。たとえば、複雑なマルチスレッドシナリオをテストするためにJUnitも使用しています。これらは「ユニットテスト」ではありませんが、JUnitがその日を支配していることは間違いありません:)
それで、あなたの質問は何ですか？ :-)同意します。ここでの真のメトリックは、開発者が単体テストの完全な実行を待機する必要がある時間です。長すぎると、コードをコミットする前に手抜きを始めます。完全なコミットビルドに1、2分もかからないようにしたいと思いますが、それが常に可能であるとは限りません。私の仕事では、コミットビルドに8分かかり、コミットする前にその一部しか実行し始めなかったので、より強力なマシンを購入しました:-)
開発者が単体テストスイートが完了するのを待つのにどれくらいの時間がかかりますか？それは、開発者が変更のフィードバックをどれだけ喜んで待つかによって異なります。遅すぎるよりも数分話し始めたら、おそらくテストスイートを個々のテストプロジェクトに分割して、別々に実行する必要があります。