创建只读DAO进行测试时的最佳做法是什么？

Question

作为我正在工作的项目的一部分，我们有一个只读的DAO（Bill类）。项目本身永远不应该创建一个尚未在数据库中表示的Bill的新实例，并且永远不应该更改或更新此Bill类的值。因此，为了防止意外修改Bill实例所有构造函数和私有，并且没有setter（Hibernate用于将数据库中的账单数据编组到Bill实例中，并且不会因缺少公共构造函数和setter而烦恼）。

现在问题：

  

作为集成测试的一部分，我需要违反我们的项目永远不会的原则   创建未在数据库中表示的新帐单对象。什么是违反的最佳方式   这个原则仅用于测试目的吗？

基于反射的构建器：我提出的一个想法是使用基于反射的构建器，以便Bill类的代码不需要更改，并且可以对构建器进行全面测试建设者对比尔等级的字段做出的任何假设都很快被识别出来。

Package-private构造函数：我老板提出的另一种方法是包含构建器可以使用的包私有构造函数。这样做的优点是更简单，并且需要更少的测试以确保构建器工作。但是，它需要在主代码库中使用显式代码来容纳它。

我们都不热衷于这两种想法。所以我想知道是否还有其他人不得不在处理类似问题之前以及如何处理它。我一直在翻阅“敏捷测试：测试人员和敏捷团队实用指南”，但到目前为止还没有找到任何相关内容。

NB。它不像直接与数据库交互那么简单，因为账单是DAO的复杂层次结构的一部分（包括数据库中的外键约束）。因此，构建者可以快速简单地创建这样的层次结构，然后将所有这些数据保存到数据库中。

Answer 1

您是否可以创建一个保存在测试源树中的MutableBill类，并将其映射到与Bill类相同的表中？

然后，您的测试代码可以在测试运行开始时使用MutableBill填充数据库（例如HSQLDB），其余代码可以继续使用不可变Bill。

Answer 2

如果我必须在这两者之间做出选择，我会使用默认的可见性构造函数。基于反射的编程创建难以理解，而不是简单的代码。您的IDE查找引用无法正常工作，因此有人可能会认为它们面临死代码。然后在运行时发现整个事情已经破碎了。

这样的添加（作为包装私人物品）是可以接受的，因为更彻底的测试是更理想的。