11

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

该网站上陈述的动机似乎非常恰当，我想知道是否有任何其他替代方案可以提供类似的功能。此外，如果专家们能够批评这种整体方法，那就太好了。

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

提前致谢！

4

1 回答 1

10

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

我只遇到过一次像您提到的问题，这是对象之间存在过多耦合的症状，因为职责范围很广。从那以后，我使用了领域驱动设计方法，我再也没有遇到过这个问题。

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

和两个建议

如果你有时间，我建议你

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