我一直在使用TDD來驅動我目前正在進行的項目，並且結果相當令人滿意。我遇到了一個問題（描述爲here;仍然沒有解決方案或任何建議！），其中有一些特定方法的某些方面可能無法進行測試（如my example;簡而言之，我希望能夠處理一個具有特定ErrorCode的ManagementException - 但我似乎不可能設置一個引發這樣的ManagementException的測試）。某些邏輯路徑固有地不可測試？
那麼，如何處理呢？我們是否簡單地接受這樣的事實：某些邏輯路徑是不可測試的（因爲我們正在使用的框架或者當前可用的測試框架的限制）？
有些設計不適合可測試性，尤其是那些沒有可測試性作爲設計目標之一的設計。一般TDDed設計不屬於這一類。
要回答你原來的問題，我已經發布了一個響應，涉及在請求的錯誤代碼中使用反射插槽。然而，這可能不適用於所有情況，並不是一個通用的解決方案。
這裏的折衷是編寫測試的努力與在自動測試下使用該特定代碼的好處。如果您認爲成本收益比率很高，並且失敗的可能性很小，那麼您可以將其作爲特殊手動測試進行編寫，對未來開發人員發表評論並現在手動進行驗證。我認爲是務實的，如果你花費了30-40分鐘的幾個開發人員的大腦時間來試驗它，也許你需要退後一步並重新考慮你的策略。查看Michael Feather的「與遺留代碼有效地合作」，瞭解克服可測試性障礙的一些建議。
我不認爲你可以說任何事情在邏輯上都是不可測試的，但是你肯定會發現在測試他們所需的努力會更好地花在其他地方的代碼領域。
確保罕見但顯着的硬件和系統錯誤得到妥善處理（這是OP正在討論的內容）不太可能成爲低迴報領域 - 因此，如果需要，值得付出實質性努力（以及關於OP的具體案例已經提出）。 – 2009-07-06 04:08:09
這是一個很好的問題，我最近也發現自己正在考慮這個問題。所以首先，我不會說一些邏輯路徑是「不可測試的」 - 最多他們可能很難用自動單元測試進行測試。您可能仍然可以通過一些嚴重的重型系統測試來測試大多數有問題的路徑。
請考慮這一點 - 您測試的任何東西都可以被認爲是在您控制的虛擬機內部運行，您可以（理論上）模擬其操作的每個方面以測試您的軟件。對於大多數應用來說這是否實用是另一個問題。
模擬某些特定的硬件和系統錯誤而沒有模擬（畢竟他是針對具有特定錯誤代碼的ManagementException）在我所知的任何虛擬機環境中都將是一個嚴重的實際困難。然而，一個虛擬機（也許帶有黑客入侵的WMI ......）實際上是另一種可能性，儘管在時間和精力方面成本很高（但如果找不到更簡單/更便宜的方法，也許值得）。 – 2009-07-06 04:08:53
我剛剛嘗試回答你原來的問題（並且在與其他人一起在midflight中相互比較，更簡潔地說相同的事情，或者至少大部分相同;-)。無論如何，肯定存在的框架太僵化了（感謝private和朋友），如果你不能用自省來解決這個問題（儘管做了所有適當的咒語），那麼你只是使用一種語言也是如此剛性以及框架。
如果整個系統支持動態語言（比如現在的.NET），比如IronRuby和IronPython，那麼我會感到驚訝 - 也許如果C＃不會讓你通過內省來訪問可訪問性限制，動態語言可以服務。
也就是說，它是肯定有可能爲整體環境設計得如此糟糕，如此嚴格以至於無法對某些東西進行單元測試 - 儘管我並不完全相信這種情況在你目前的情況下。
有些東西不能在自動單元測試中測試，因爲語言/框架/情況只是不開放給它。處理這個問題的方法是儘可能減少這個區域，並且保持它的簡單性，以至於不太可能成爲後來的錯誤或行爲改變的源頭。
除了單元測試外，還有更多的測試，而且這些領域（如驗收測試，質量保證等）也不在單元測試中。
我已經在你的鏈接q中提出了一個建議。 – Robert 2009-07-06 03:52:03