私は現在、k秒ごとにn回アクションを実行する、シンプルなタイマーベースのミニアプリをC＃で作成しています。
私はテスト駆動開発スタイルを採用しようとしているので、私の目標はアプリのすべての部分を単体テストすることです。
だから、私の質問は：タイマーベースのクラスをユニットテストする良い方法はありますか？
問題は、私が見ているように、テストの実行に不快な時間がかかるという大きなリスクがあることです。これは、テストが目的のアクションが発生するまで非常に長く待たなければならないためです。
特に、フレームワークで許可されている最小の時間分解能（1ミリ秒？）を使用する代わりに、現実的なデータ（秒）が必要な場合。
アクションにモックオブジェクトを使用して、アクションが呼び出された回数を登録しているので、アクションは実質的に時間がかかりません。
私が行ったことは、タイマーと現在のシステム時刻をモックして、イベントをすぐにトリガーできるようにすることですが、テスト対象のコードに関する限り、経過時間は秒でした。
Len Holgateは、タイマー ベースのコードのテストに関する 20の一連の記事を書いています。
この場合、シーケンス全体ではなく、タイマーが作動したときに実際に実行されるコードをテストすることになると思います。本当に決定する必要があるのは、アプリケーションの実際の動作をテストする価値があるかどうか（たとえば、すべてのティックが1つのティックから別のティックに大幅に変化した後に何が起こるか）、またはそれで十分かどうか（つまり、 、アクションは毎回同じです）ロジックをテストするだけです。
タイマーの動作は決して変更されないことが保証されているため、タイマーは正しく機能するか（つまり、正しく構成されているか）、そうでないかのどちらかです。実際に必要がなければ、それをテストに含めるのは無駄な努力のようです。
ユニットテストの観点から、タイマーメカニズムを単に忘れて、アクション自体が期待どおりに機能することを確認することがおそらく理にかなっている限り、私はダニーに同意します。また、ある種の自動テストスイートにタイマーの構成を含めるのは無駄な努力であるという点でも同意しません。タイミングアプリケーションの操作に関しては、多くのエッジケースがあり、テストしやすいものだけをテストするだけで、誤った安心感を生み出すのは非常に簡単です。
実際のアクションだけでなく、タイマーを実行する一連のテストを用意することをお勧めします。このスイートはおそらく実行に時間がかかり、ローカルマシンで常に実行するものではない可能性があります。しかし、これらのタイプのものを夜間の自動ビルドに設定すると、バグを見つけて修正するのが難しくなる前に、バグを根絶するのに役立ちます。
要するに、あなたの質問に対する私の答えは、実行に長い時間がかかるいくつかのテストを書くことについて心配しないでください。できることを単体テストし、そのテストスイートを高速かつ頻繁に実行しますが、実行頻度は低くなりますが、アプリケーションとその構成の多くをカバーする統合テストでそれを補完するようにしてください。