Question

所以标准的敏捷哲学会建议你的域类是简单的POCO，这些POCO是通过数据访问对象使用单独的代理层保持的（就像NHibernate那样）。它还建议尽可能提高单元测试覆盖率。

为这些简单的POCO对象编写测试是否有意义？假设我有一个看起来像这样的课程：

public class Container {
 public int ContainerId { get; set;}
 public string Name { get; set;}
 public IList<Item> Contents { get; set;}
}

我可以为此写一些有用的单元测试吗？

Answer 1

通常，像这样的值对象不需要拥有自己的测试。您将从使用它的类中获得实际操作的覆盖范围。

单元测试旨在测试行为。没有行为？无需测试。

Answer 2

实际上，我认为如果您在编写课程之前开始为此代码编写测试，那么您的实现将会有所不同。例如，您可能最终编写一个初始化集合的构造函数，以便您可以引用它而无需每次都检查null。我认为即使您认为不需要它们，也可以编写测试。通常在编写测试时，您会发现有很多假设是您在第一次尝试代码时无法解决的。

例如，ContainerId是否可能小于零？尝试将其设置为负值会是错误的吗？是否应该由构造函数初始化集合，即，使用此容器类的类是否必须在访问之前检查null，或者您是否希望保证集合永远不会为null，尽管它可能为空？

那就是说，我通常对这个过程应用一些理智。例如，如果我知道构造函数是内部作用域的，对象只是由Factory类创建的。我将测试工厂方法以确保它们始终生成合法对象，但不一定要测试容器类本身。

对我来说，无论如何，我认为底线是假设类需要测试，尝试编写它们，并且只有当我想不出有意义的测试时才省略它们。

Answer 3

这只是我的习惯，我绝不是最终所有这一切，但我没有编写测试，直到我有一个实际做某事的构造函数（即设置默认值）。

您需要测试自己的代码，而不是语言。无论什么时候新的Container（），你都会得到一个新的容器。而且，如果你搞砸了那一步，编译器就会抓住它。

Answer 4

我喜欢将单元测试视为“呼唤”一个意图单元。

您的代码表示的唯一意图是getter和setter;作为语言的一部分，我们假设这些工作。

没有表达其他意图，因此不需要进行任何测试。

但我建议从Contents属性中删除setter。 Collection properties should be read-only.

Answer 5

我认为这甚至不是一个对象 - 对象是由它的行为定义的，而这个类没有任何对象。这是一个纯粹的数据容器。也可以拥有它们 - 而且它们通常不需要任何测试 - 但要注意你最终不会得到Anemic Domain Model。使用测试驱动开发会“迫使”您首先考虑类的行为，并且可能是一个很好的练习。