タイマーベースのアプリケーションの単体テストを行っていますか?

Question

私は現在、k 秒ごとに n 回アクションを実行するシンプルなタイマーベースのミニアプリを C# で作成しています。
私はテスト駆動開発スタイルを採用しようとしているので、私の目標はアプリのすべての部分を単体テストすることです。

そこで、私の質問は次のとおりです。タイマーベースのクラスを単体テストする良い方法はありますか?

私が考えるに、問題は、テストの実行に不快なほど長い時間がかかるという大きなリスクがあることです。テストは、必要なアクションが発生するまで非常に長く待たなければならないためです。
特に、フレームワークで許可されている最小時間解像度 (1 ミリ秒?) を使用するのではなく、現実的なデータ (秒) が必要な場合はそうです。
アクションにモック オブジェクトを使用して、アクションが呼び出された回数を登録し、アクションに実質的に時間がかからないようにしています。

Answer 1

私がやったことは、タイマーと現在のシステム時刻を模擬して、イベントをすぐにトリガーできるようにすることですが、テスト対象のコードに関する限り、経過時間は数秒でした。

Answer 2

レン・ホルゲー​​ト シリーズがあります タイマーベースのコードのテストに関する 20 件の記事.

Answer 3

この場合、シーケンス全体ではなく、タイマーが鳴ったときに実際に実行されるコードをテストすることになると思います。本当に決定する必要があるのは、アプリケーションの実際の動作をテストする価値があるかどうか (たとえば、各ティックの後に何が起こるかが、あるティックから別のティックに大きく変化するかどうか)、またはそれだけで十分であるかどうかです。 、アクションは毎回同じです）ロジックをテストするだけです。

タイマーの動作は決して変わらないことが保証されているため、正しく動作する (つまり、正しく設定されている) かどうかのどちらかです。実際に必要がない場合に、それをテストに含めるのは無駄な労力であるように思えます。

Answer 4

私も Danny の意見に同意します。単体テストの観点からは、タイマー メカニズムを単に忘れて、アクション自体が期待どおりに動作することを確認するだけでよいと考えられます。また、ある種の自動テスト スイートにタイマーの構成を含めるのは無駄な労力であるという点で、私は同意しません。タイミング アプリケーションの操作には多くのエッジ ケースがあり、テストしやすいものだけをテストすることで誤ったセキュリティ感を生み出すことが非常に簡単です。

実際のアクションだけでなくタイマーを実行する一連のテストを用意することをお勧めします。このスイートの実行にはおそらく時間がかかり、ローカル マシンで常に実行するものではないと思われます。しかし、このような種類のものを夜間の自動ビルドに設定すると、バグを見つけて修正するのが難しくなる前に根絶するのに非常に役立ちます。

つまり、あなたの質問に対する私の答えは、実行に時間がかかるいくつかのテストを書くことについて心配する必要はない、ということです。できることは単体テストして、そのテスト スイートを高速かつ頻繁に実行できるようにします。ただし、実行頻度は低くても、より多くのアプリケーションとその構成をカバーする統合テストでそれを補ってください。