应该为简单的 POCO 域对象编写哪些单元测试？答案

【问题标题】：What unit tests should be written for simple POCO domain objects?应该为简单的 POCO 域对象编写哪些单元测试？
【发布时间】：2008-11-15 21:34:30
【问题描述】：

因此，标准的敏捷哲学建议让您的域类成为简单的 POCO，这些 POCO 通过数据访问对象使用单独的代理层进行持久化（就像 NHibernate 那样）。它还建议获得尽可能高的单元测试覆盖率。

为这些简单的 POCO 对象编写测试是否有意义？假设我有一个如下所示的课程：

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

我可以为此编写哪些有用的单元测试？

【问题讨论】：

我发现有用的一种方法是测试您的 Pocos 不会以任何方式改变数据。例如，OpenPojo 是一个 Java 库，它就是这样做的。

标签： .net unit-testing agile

【解决方案1】：

通常，像这样的值对象不需要有自己的测试。您将从使用它来实际做某事的类中获得覆盖。

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

【讨论】：

我想我们都同意这一点。但是当代码通过“分析器”运行时，它说你只有例如当最后 20% 是一堆 POCO 时，80% 的覆盖率。祝你好运，向管理层解释这一点。
@CaptainKenpachi：正如 Jeffrey 所说，“你会从使用它来实际做某事的课程中获得报道。”
也很容易向管理层解释 - 这些指标是一种开发工具，而不是管理工具，它们与管理的相关性与代码行或查看依赖关系树一样。

【解决方案2】：

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

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

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

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

【讨论】：

【解决方案3】：

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

您需要测试自己的代码，而不是语言。每当您使用 new Container() 时，您都会得到保证，您将获得一个新的 Container。而且，如果你确实搞砸了这一步，编译器就会捕捉到它。

【讨论】：

【解决方案4】：

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

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

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

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

【讨论】：

以前从未听说过，但有道理

【解决方案5】：

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

【讨论】：