为嵌套对象的单元测试用例生成测试数据

Question

在模拟为任何企业级 java 服务编写单元测试用例的依赖服务时，我发现为单元测试用例设置数据非常痛苦。大多数时候，这是开发人员不编写单元测试用例而是编写集成式测试用例的最令人信服的理由。如果服务依赖于其他几个服务（依赖于它们各自的 DAO）和它自己的 DAO，则为合理嵌套的对象生成 when-thenReturn 子句将变得相当费力，并且开发人员被视为采取了简单的路线并加载整个弹簧上下文并从直接来源获取数据，这些来源可能并不总是提供可以遍历所有必需代码路径的数据。在此背景下，我的一位同事建议为什么不运行示例集成测试，并使用方面，捕获所有相关数据点并将其序列化为 XML 表示，该表示可用于实现单元测试的测试数据案例。令我们惊喜的是，我们发现了一个名为TestDataCaptureJ on github 的框架，它与此非常相似。它使用方面来捕获数据点，并生成 java 代码来创建对象。

网站上声明的motivation 似乎非常贴切，我想知道是否有任何其他替代方案可以提供类似的功能。此外，如果专家能够批评这种整体方法，那就太好了。

此外，该项目大约有 2 年的历史，并且有一些我们必须修复的错误，并希望将其作为 mavenized github fork 归还。只需检查以确保其中一个著名的马厩也没有其他类似的举措。

提前致谢！

Answer 1

我对这种方法有两个批评...请记住，我对您的上下文的了解几乎为零，这意味着我在这里的建议可能对您不起作用。

我只遇到过一次像您提到的问题，这是对象之间存在过多耦合的症状，因为责任方式过于广泛。从那以后我使用Domain-Driven Design 方法，我再也没有遇到过这个问题。

我更喜欢使用Test-Data Builders 来创建测试数据。这种方法允许我拥有我想要构建的模板，并且只需替换我对测试感兴趣的部分。如果您决定采用这种方式，我强烈建议您使用一个名为 Make-It-Easy 的小型库，以简化这些构建器的创建。

还有两个建议

如果你有时间，我建议你去

1. 观看 Michael Feathers 的名为 The Deep Synergy Between Testability and Good Design 的预设 - 谈话的一部分内容与您正在经历的事情非常相似。
2. 阅读本书Growing Object-Orieted Systems, Guided by Tests（又名GOOS），它对如何编写简单、令人惊叹、可测试的代码有各种见解。