因此，标准的敏捷开发理念建议将您的领域类设计成简单的POCO，并通过数据访问对象（例如NHibernate）使用单独的代理层进行持久化。它还建议尽可能高地覆盖单元测试。
对于这些简单的POCO对象编写测试有意义吗？比如我有一个看起来像这样的类：
public class Container {
public int ContainerId { get; set;}
public string Name { get; set;}
public IList<Item> Contents { get; set;}
}
我可以为此编写哪些有用的单元测试？
通常像这样的值对象不需要拥有自己的测试。你可以从使用它实际执行某些操作的类中获取覆盖率。
单元测试旨在测试行为。没有行为？就没有必要进行测试。
这只是我的习惯，并不代表我是测试的终极标准。但在编写测试之前，我通常会先编写一个实际完成某些任务（例如设置默认值）的构造函数。
你需要测试自己编写的代码，而非语言本身。每当你新建一个 Container() 对象时，你都能得到一个全新的 Container。如果你在这一步出了问题，编译器会提示错误。
我喜欢把单元测试看作是“呼叫”意图单元。
你的代码表达的唯一意图是获取器和设置器；作为语言的一部分，我们假设它们有效。
没有其他意图被表达，因此不需要测试。
然而，我建议从Contents属性中删除设置器。集合属性应该是只读的。