我想，我終於開始明白打算什麼單元測試來解決，但我仍然有實現所有的麻煩的細節。我得出的結論是，我可能需要一個「模擬」（因爲我不確定是否需要像Moq這樣的整個框架）對象才能完成工作，所以我可能需要一個「模擬」（並且我輕鬆使用這個術語）。
作爲我一直在運行的問題的一個示例，請考慮Repository Pattern（或類似）的實現。正如我目前所瞭解的那樣，我需要（至少）對Add()，Get()和Remove()類方法中的每一個進行測試。這很好，除了我想測試Add()方法如何處理null引用。在這種情況下，我只需要在測試項目中定義一個簡單的類，並在適當的單元測試中將其設置爲null？
例單元測試（插圖）：
我會去儘量地說，軟件測試，是像矩陣。沒有人可以被告知什麼是軟件測試，你必須自己看看。大多數非信徒沒有給出一個公平的機會，也從來沒有嘗試過做一些測試。歡迎來到俱樂部！
雖然測試的棘手問題是編寫測試非常困難，但編寫可測試的代碼有時也很具挑戰性。然而，今天有很多很棒的工具和技術，您應該投資成爲一名更好的軟件工程師。
嘲笑提供了你不得不自己寫的傻瓜，嘲笑很方便。在這種情況下，您的存儲庫不是一個實際的持久性服務，它只是提供一個測試合同。如果不應該添加空引用，則應該有一個預期這種操作失敗的測試用例。我相信這是不言而喻的，但對此進行測試很重要。
一個像Moq這樣的庫可能在這裏非常有用，因爲一個虛擬存儲庫什麼都不做，而且你實際上需要在這裏發生斷言。我不明白在這裏需要添加東西后屬性Entity（除了可能使編寫測試更容易）。但我也認爲這是斷言預期行爲的錯誤方式。
在某種程度上，您所做的實際上是指集成測試，因爲您不是在測試使用模擬工廠來測試兩個組件之間交互的獨立單元。這些類型的測試非常重要，但如果它們不是可測試的，也很難處理。這就是爲什麼我們有諸如依賴注入之類的東西。
你的問題並不需要特定的答案，但是你在正確的軌道上，我希望這會給你一些洞察力和進行軟件測試時的額外信心。
感謝您的見解。我繼續在Moq上做了一些閱讀，可以看到它對於快速原型（其中每個測試或多或少等同於可運行psuedocode）以及我想驗證某個特定模擬對象的成員實際上是被調用或設置的。但是，我沒有發現（並且認爲在許多測試場景中會非常有用）是能夠驗證模擬對象成員中特定語句或調用的執行情況。 – 2011-06-05 13:16:15
爲了擴展這個想法......至少驗證Add（）方法中的特定語句是否被執行（或者更現實的是，在例程中達到了一個局部點），這對於非空值（以及反之亦然）。然而，我不確定這個功能在任何框架中都沒有實現（儘管我可能錯過了它）。 – 2011-06-05 13:18:44
Moq沒有使用這些記錄/重放成語，甚至聲稱沒有必要，我沒有看到，但它可能值得檢查。 – 2011-06-05 16:20:49
爲什麼不直接使用'object'？ – 2011-06-05 08:58:42
@Richard Szalay，工作原理是一樣的。我使用'MockObject'的意圖是讓我知道我對模擬對象和預期用途的理解非常有限。在做了更多的研究之後，我開始認爲'MockObject'應該是'StubObject'。我想我會拭目以待。 – 2011-06-05 09:42:12