testing - 持久化复杂的测试数据

Question

我们正在使用构建器模式来生成测试数据。这些域对象之间存在关系。我们的功能测试需要保留这些对象。

想想这个模型:

如果我想要一个普通的 C 实例，我可以执行 aNew().c().build()

如果我想让它持久化，我会执行 aNew().c().saveIn(session)

如果我想要一个具有已知 B 的 C 实例，我可以执行 aNew().c().with(b).build()

好吧，你明白了。我的问题是，如果我想坚持 C，它应该坚持 B 吗？还是应该事先坚持？如果我想要一个合理的默认 B 怎么办？如果我想坚持一个D呢？它应该保留所有 A、B、C 吗？

当然，真实系统要复杂得多(有时带有循环引用)。我正在寻找持久保存复杂测试数据的最佳实践。

编辑: 看来我遇到了语言障碍，我的母语不是英语，所以很抱歉晦涩难懂。这里有更多信息:

• 我要测试的不是遗留代码
• 我正在尝试编写覆盖测试，而不是单元测试(因此我不会 mock 任何东西)
• 如果数据库在某种程度上被填充(它不使用所有实体)，我正在尝试测试的软件就可以工作。

附言。请不要犹豫，索取更多信息，因为我一直在努力寻找可能的最佳实践。我想到的最接近的是:

1. 在构建实体时跟踪明确设置的内容。
2. 假设显式设置的实体已经持久化，不要持久化它们。
3. 坚持其他一切(与他们自己的坚持者)。

这行得通，但我的蜘蛛感觉很刺痛，我想我做错了什么，因为测试代码中会涉及逻辑，如果没有测试处理起来会非常复杂。

编辑 2: 我会尽量让自己更清楚。当我编写/运行我的单元和一些集成测试时，我没有任何问题，因为测试数据不会持久化，它存在于内存中。

但是当我尝试保留我的测试数据时，hibernate 不会让我保存没有关系的实体。

我怎样才能克服这个问题？

Answer 1

您可能应该更详细地描述您的测试设置。特别是，为什么您的功能测试需要保留这些对象？您正在测试实际的持久性操作吗？或者这只是运行测试的副作用？您想加载持久对象作为测试的一部分吗？

My problem is, if I want to persist a C, should it persist it's B? Or should it be persisted before hand?

这首先取决于您坚持的原因。如果您正在对持久层进行集成测试，那么您应该只使用应用程序本身使用的逻辑。如果它只是测试的副作用，您可能想要模拟持久层等...