在单元测试中创建对象的最佳实践？答案

【问题标题】：Best practice for object creation in unit tests?在单元测试中创建对象的最佳实践？
【发布时间】：2014-04-24 04:40:22
【问题描述】：

对于我的单元测试，我需要很多特定的、大型（许多字段）对象。我的所有测试类都需要多个 不同的 实例。据我所知，我有几个选择，我想知道什么是最好的：

扩展类的构造函数，但我冒着伸缩模式的风险
在每个测试类中编写方法来为我创建对象
实现builder pattern，但在重构我的应用程序时浪费了很多时间
使用根据给定参数为我创建对象的实用程序类

我认为最好的选择是使用构建器模式，但这是最困难的，因为我没有太多时间进行重构。所以我认为下一个最好的事情是使用实用程序类。这是一个好的做法还是更好的选择？如果这主要是基于意见，我表示歉意。

【问题讨论】：

您是否尝试过任何为单元测试而开发的现有框架？他们可能会根据您使用的技术为您提供帮助。
不，我还没有尝试过。是否有创建所需对象的框架？我真的没有看到为此使用框架的优势。
单元测试的重点是覆盖并确保系统在所有情况下（即异常情况）都能恢复。与 C++ 一样，有一个框架 CPPTTest。

【解决方案1】：

如果您的代码中仍然没有构建器，这意味着以下 3 件事之一：您有一个简单的 CRUD，您的代码真的很糟糕，或者您的对象是以极少数方式/少数地方创建的。我假设最后一种情况。所以使用工厂——你的最后一个选择。但是如果您在对象创建过程中涉及任何逻辑，那么您仍然应该重构您的代码并在您的生产代码和测试中使用相同的逻辑/相同的工厂。否则，您将冒险测试与您在生产中拥有的完全不同的对象。即使现在您将逻辑复制/粘贴到您的测试中，那么几个月后您的测试对象将与您的生产对象不同。

“逻辑”是指任何类型的非空检查、断言、前提条件、字段转换等

【讨论】：

【解决方案2】：

在我看来，abstract factory pattern 会让您受益匪浅。这基本上就是您在最后一点中的建议。

为您的测试创建一个特定的工厂并没有错。

【讨论】：

我认为工厂模式用于创建某个接口的所需实现。这不是我想要的，我正在尝试找到最好和最可重用的方法来创建（例如）具有姓名、性别、...的人。
也许抽象工厂太过分了。但是您仍然可以创建一个具有相当先进的创建者方法的工厂，这可能会减少大量手动参数传递，甚至可以将它们随机化，尽管我猜这对于测试用例来说不是一个好主意。例如，您可以将所有参数存储在工厂中，然后只将您想要更改的参数传递给创建者方法。