我目前正在C＃中編寫一個簡單的基於計時器的迷你應用程序，每k秒執行一次動作n次。
我試圖採用測試驅動的開發風格，所以我的目標是單元測試應用程序的所有部分。單元測試基於計時器的應用程序？
所以，我的問題是：有單位測試基於計時器的類的好方法嗎？
正如我所看到的那樣，問題在於測試將花費很長的時間執行很大的風險，因爲他們必須等待期望的動作發生。
特別是如果你想要現實的數據（秒），而不是使用框架允許的最小時間分辨率（1毫秒？）。
我正在使用模擬對象執行操作，註冊操作次數被調用的次數，以便該操作幾乎不需要任何時間。
我所做的就是模擬計時器和當前系統時間，我的事件可以立即觸發，但是就測試中的代碼而言，時間流逝是秒。
我想在這種情況下我會做的是測試當計時器滴答時實際執行的代碼，而不是整個序列。你真正需要決定的是，測試應用程序的實際行爲是否值得（例如，如果在每個時間點之間發生的變化從一個時間點到另一個時間點發生劇烈變化），還是足夠了（也就是說，每次操作都是一樣的）來測試你的邏輯。由於定時器的行爲保證永不改變，它可以正常工作（也就是說，你已經正確配置了它）;或者不是，如果你實際上不需要，似乎是浪費精力將它包含在你的測試中。
我同意丹尼的觀點，因爲從單元測試的角度來看，它可能有意義，只是忘記了計時器機制，只驗證動作本身如預期那樣工作。我也會說我不同意，因爲把定時器的配置包含在某種自動化測試套件中是浪費時間的。在處理定時應用程序時有很多邊緣情況，只通過測試容易測試的東西來創建錯誤的安全感很容易。
我會建議有一套測試運行計時器以及實際行動。該套件可能需要一段時間才能運行，並且可能不會在本地計算機上始終運行。但是，在夜間自動構建這些類型的東西時，確實有助於在錯誤難以發現和修復之前消除錯誤。
所以總之，我對你的問題的回答是不用擔心編寫幾個需要很長時間才能運行的測試。單元測試你可以做什麼，並使這個測試套件能夠快速而經常地運行，但是確保使用運行頻率較低但涵蓋更多應用程序及其配置的集成測試進行補充。
我看到你的方法唯一的問題是，你可能不得不暴露每次民意調查發生的事情，這是一個好主意嗎？即暴露你不需要進行測試的東西。另一種選擇可能是內部的（和InternalsVisibleTo），但很多人也不喜歡這樣做 – roundcrisis 2012-09-13 11:22:37