因此，標準的敏捷哲學會建議讓你的領域類簡單POCOs，它們是通過數據訪問對象（像NHibernate那樣）使用單獨的代理層持久化的。它還建議獲得儘可能高的單元測試覆蓋率。應該爲簡單的POCO域對象編寫哪些單元測試？
爲這些簡單的POCO對象編寫測試有意義嗎？假設我有這樣的課程：
public class Container {
public int ContainerId { get; set;}
public string Name { get; set;}
public IList<Item> Contents { get; set;}
}
我可以爲此編寫哪些有用的單元測試？
這只是我的習慣，而我絕不是最終所有人都會這樣做的，但是我不寫測試，直到我有一個實際做某事的構造函數（即設置默認值）。
您需要測試自己的代碼，而不是語言。只要你新的Container（）你將得到一個新的Container，你就會得到保證。而且，如果你搞砸了這一步，編譯器會抓住它。
我喜歡將單元測試視爲「調出」一個意圖單元。
你的代碼表達的唯一意圖是getter和setter;作爲語言的一部分，我們承擔這些工作。
沒有其他意圖表達，因此不需要測試。
但是，我建議從Contents屬性中移除setter。 Collection properties should be read-only.
其實，我認爲如果你在編寫這個類之前就開始爲這段代碼編寫測試，你的實現將會有所不同。例如，您最終可能會寫一個構造函數來初始化您的集合，以便您可以引用它，而不必每次都檢查null。我認爲即使你認爲你不需要他們，也可以編寫測試。通常在編寫測試時，你會發現有很多假設是你第一次嘗試編碼時沒有解決的。
例如，ContainerId可以小於零嗎？嘗試將其設置爲負值會產生錯誤嗎？集合是否應該由構造函數初始化，也就是說，使用這個容器類的類在訪問之前是否必須檢查null，還是要保證集合永遠不會爲null，儘管它可能是空的？
這就是說，我通常對過程應用一些理智。例如，如果我知道構造函數是內部作用域的，而對象只是由Factory類創建的。我將測試工廠方法以確保它們始終生成合法對象，但不一定會測試容器類本身。
對於我來說，無論如何，我想底線是假設類需要測試，試圖寫它們，並且只有在我想不出有意義的測試寫時纔會省略它們。
通常，像這樣的值對象不需要有自己的測試。你會從使用它的類中獲得實際上做某事的報道。
單元測試旨在測試行爲。沒有行爲？不需要測試。
我想我們都同意這一點。但是當代碼運行通過「分析器」時，它說你只有例如當最後的20％是一組POCO時，覆蓋率達到80％。祝好運向管理層解釋。 – 2017-10-11 08:42:45
我認爲這不是一個對象 - 對象是由它的行爲定義的，而這個類沒有任何對象。這是一個純數據容器。也可以擁有這些 - 他們通常不需要進行任何測試 - 但要注意，最終不會得到Anemic Domain Model。使用測試驅動開發會「迫使」你首先考慮你的類的行爲，這可能是一個很好的練習。
從來沒有聽說過，但有道理 – 2008-11-15 21:49:30