当嘲笑为任何企业级java服务编写单元测试用例的依赖服务时，我发现为单元测试用例设置数据是一件非常痛苦的事情。大多数情况下，这是开发人员不编写单元测试用例，而是编写集成风格测试用例的唯一最令人信服的原因。如果服务依赖于其他服务(依赖于它们各自的DAO)和它自己的DAO，为一个合理嵌套的对象生成when-thenReturn子句是一项相当艰巨的工作，开发人员被认为采取了简单的方法，加载了整个spring上下文，并从直接源中获取数据，这些直接源可能并不总是提供可以遍历所有所需代码路径的数据。在这种背景下，我的一位同事建议，为什么不运行一个示例集成测试，并使用方面来捕获所有相关的数据点，并将其序列化为XML表示，该XML表示可以用于具体化单元测试用例的测试数据。令我们惊喜的是，我们在github上发现了一个名为TestDataCaptureJ的框架，它与此非常相似。它使用方面来捕获数据点，并生成java代码来创建对象。
网站上所说的动机似乎非常恰当，我想知道是否有其他替代方案可以提供类似的功能。此外，如果专家们能够对这种整体方法进行批评，那将是一件很棒的事情。
此外，该项目已经有2年的历史了，有一些错误，我们必须修复，并希望将其作为一个专业的github分支来归还。只是检查一下，以确保没有其他类似的举措来自知名的马厩。
提前感谢！
我对这种方法有两个批评。。。请记住，我对你的背景几乎一无所知，这意味着我在这里的建议可能对你不起作用。
我只经历过一次像你提到的那样的问题，这是对象之间耦合过多的症状，因为责任是从到的方式。从那以后，我使用领域驱动的设计方法，我再也没有遇到过这个问题。
我更喜欢使用测试数据生成器来创建测试数据。这种方法允许我有一个我想要构建的模板，只需替换我对测试感兴趣的部分。如果你决定这样做，我强烈建议你使用一个名为Make It Easy的小型库，它可以简化这些构建器的创建。
还有两个建议
如果你有时间，我建议你去
- 观看Michael Feathers的一个名为"可测试性和良好设计之间的深度协同"的预设节目-部分内容是关于与你所经历的非常相似的事情
- 阅读《成长的面向对象系统，以测试为导向》(又名GOOS)一书，它对如何编写简单、神奇、可测试的代码有着各种各样的见解