単体テストでどのような実行率を目指していますか (1 秒あたりのテスト数)? 個々の単体テストにはどれくらいの時間がかかりますか?
テストが遅すぎるかどうかを判断するための特定のしきい値があるかどうかを知りたいと思いますか、それとも長時間実行されるテストスイートの摩擦があなたを良くするときだけですか?
最後に、テストをより高速に実行する必要があると判断した場合、テストを高速化するためにどのような手法を使用しますか?
注: 統合テストは明らかに別の問題です。できるだけ頻繁に実行する必要がある単体テストを厳密に話しています。
回答のまとめ:これまで素晴らしい回答をありがとうございました。ほとんどのアドバイスは、速度について心配する必要はないようです。品質に集中し、遅すぎる場合は選択的に実行してください。特定の数値を含む回答には、テストごとに最大 0.5 および 1 秒まで 10 ミリ秒未満を目指すこと、または一般的に実行される一連のテスト全体を 10 秒未満に保つことが含まれます。
それらがすべて役立つ場合に、「受け入れられた回答」としてマークするのが正しいかどうかはわかりません:)
すべての単体テストは 1 秒未満で実行する必要があります (つまり、すべての単体テストを組み合わせて 1 秒で実行する必要があります)。これには実際的な制限があると確信していますが、ラップトップでこれほど高速に実行される 1000 個のテストを含むプロジェクトがありました。開発者がモデルのコア部分のリファクタリングを恐れないように、この速度が本当に必要になります (つまり、これらのテストを実行している間、Lemme はコーヒーを飲みに行きます... 10 分後に Lemme は戻ってきます)。
この要件は、アプリケーションを正しく設計することも強制します。これは、ドメイン モデルが純粋であり、あらゆる種類の永続性 (ファイル I/O、データベースなど) への参照が含まれていないことを意味します。単体テストは、これらのビジネス関係をテストするためのものです。
これは、データベースや永続性のテストを無視するという意味ではありません。しかし、これらの問題は、別のプロジェクトにある統合テストで個別にテストできるリポジトリの背後に隔離されています。ドメイン コードを記述するときに単体テストを定期的に実行し、チェックイン時に統合テストを 1 回実行します。
目標は、1 秒あたり数百回のテストです。そこにたどり着く方法は、Michael Feather の単体テストのルールに従うことです。
過去のCITCONの議論で出てきた重要なポイントは、テストがこれほど高速でない場合、単体テストの設計上の利点が得られない可能性が非常に高いということです。
厳密に単体テストについて話している場合は、速度よりも完全性を目指します。実行時に摩擦が生じ始めた場合は、テストを別のプロジェクト/クラスなどに分割し、作業中のテストのみを実行します。インテグレーション サーバーがチェックイン時にすべてのテストを実行できるようにします。
私はテストの速度よりも読みやすさに重点を置く傾向があります。ただし、私はまだそれらを適度に高速にしようとしています。ミリ秒単位で動いていれば大丈夫だと思います。テストごとに 1 秒以上実行する場合は、最適化する必要があることを行っている可能性があります。
遅いテストは、システムが成熟し、ビルドに数時間かかる場合にのみ問題になります。その時点で、簡単に最適化できる 1 つまたは 2 つのテストではなく、多くの種類の遅いテストの問題に遭遇する可能性が高くなります。 . したがって、多くのテストがそれぞれ数百ミリ秒 (またはさらに悪いことに、それぞれ数秒) 実行されている場合は、数百のテストに到達するまで待つのではなく、すぐに注意を払う必要があります。問題を解決するのは本当に難しい）。
それでも、自動ビルドでエラーが発生するまでの時間を短縮するだけです... 1 時間後 (または数時間後) であれば問題ないと思います。問題は、チェックインする前にそれらを実行することですが、これは、作業中のものに関連するテストの小さなサブセットを選択して実行することで回避できます。実行していないテストを壊すコードをチェックインした場合は、必ずビルドを修正してください!
現在、約 3 秒で 270 のテストを行っています。ファイル IO を実行するテストはおそらく 8 つほどあります。
これらは、すべてのエンジニア マシンでライブラリのビルドが成功すると自動的に実行されます。ビルド マシンによって毎晩行われる、またはエンジニア マシンで手動で開始できる、より大規模な (そして時間のかかる) スモーク テストがあります。
ご覧のとおり、テストに時間がかかりすぎるという問題にはまだ到達していません。私にとって 10 秒は、それが邪魔になり始めるポイントです。頻繁に変更されず、依存関係がほとんどないため、より堅牢な下位レベルのライブラリをナイトリー ビルド、またはビルド マシンによってのみ実行される構成に移動する可能性があります。
100 ほどのテストを実行するのに数秒以上かかることがわかった場合は、何を単体テストとして分類しているか、スモーク テストとして扱う方がよいかどうかを調べる必要があるかもしれません。
あなたのマイレージは、開発の分野によって明らかに大きく異なります。
データ ポイント -- Python 回帰テスト
Python 2.5.2 の「make test」を実行するための私のラップトップでの数値は次のとおりです。
単体テストは、1 秒あたりのテスト数ではなく、テストごとに判断します。私が目指すレートは500ms以下です。それを超える場合は、テストに時間がかかる理由を調べます。
テストが遅いと思うとき、それは通常、やりすぎていることを意味します。したがって、テストを複数のテストに分割してリファクタリングするだけで、通常はうまくいきます。テストの実行速度が遅いことに気付いた他の場合は、テストがコードのボトルネックを示している場合で、コードのリファクタリングが必要です。
単体テストに関する最も重要なルールの 1 つは、高速に実行する必要があるということです。
個々の単体テストにはどれくらいの時間がかかりますか?
開発者は、ユニット テストのスイート全体を数秒で実行できる必要があります。とにかく、開発者はコードを変更した後、すぐにそれらを実行できるはずです。時間がかかりすぎると、彼らはそれらを実行しようとせず、テストの主なメリットの 1 つを失うことになります。
単体テストでどのような実行率を目指していますか (1 秒あたりのテスト数)?
各テストがミリ秒単位で実行されるようにする必要があります。1 秒を超えると、おそらくテストが多すぎます。
現在、30 秒未満で実行される約 800 個のテストがあり、1 秒あたり約 27 個のテストです。これには、それらを実行するために必要なモバイル エミュレーターを起動する時間が含まれます。それらのほとんどはそれぞれ0〜5ミリ秒かかります（私の記憶が正しければ）。
おそらくチェックの候補となる、約 3 秒かかる 1 つまたは 2 つのものがありますが、重要なことは、テスト スイート全体がそれほど長くかからず、開発者がそれを実行するのを遅らせず、継続的な処理を大幅に遅くしないことです。統合ビルド。
また、構成可能なタイムアウト制限を 5 秒に設定しています。これより長くかかるものはすべて失敗します。
一部のフレームワークは、最終変更時刻などのヒューリスティックに基づいて、特定の単体テストを自動的に実行します。Ruby と Rails の場合、AutoTest を使用すると、テストの実行がはるかに高速で応答性が向上します。Rails モデルを保存するapp/models/foo.rbと、対応する単体テストtest/unit/foo_test.rbが実行されます。
他のプラットフォームに同様のものが存在するかどうかはわかりませんが、それは理にかなっています.
個々の単体テストにはどれくらいの時間がかかりますか?
コンパイル速度に依存すると思います。通常、コンパイルごとにテストを実行します。単体テストの目的は速度を落とすことではなく、「何も壊れていない、続行する」(または「何かが壊れた、停止する」) というメッセージを表示することです。
これが面倒になり始めるまで、テストの実行速度については気にしません。
危険なのは、遅すぎるという理由でテストの実行を停止することです。
最後に、テストをより高速に実行する必要があると判断した場合、テストを高速化するためにどのような手法を使用しますか?
最初にすべきことは、なぜそれらが遅すぎるのか、そして問題が単体テストにあるのか、それともテスト対象のコードにあるのかを突き止めることです。
テスト スイートをいくつかの論理的な部分に分割して、コンパイルのたびに変更したコードの影響を受けると思われる部分だけを実行し ます。他のスイートを実行する頻度を減らし、おそらく 1 日 1 回か、何かを壊した可能性があると疑わしい場合に、少なくとも統合する前に実行します。