为嵌套对象的单元测试用例生成测试数据 [英] Generating test data for unit test cases for nested objects

问题描述

在模拟依赖服务来为任何企业级Java服务编写单元测试用例时，我发现为单元测试用例设置数据非常麻烦.在大多数情况下，这是开发人员不编写单元测试用例，而是编写集成式测试用例的唯一最引人注目的原因.如果该服务依赖于其他几个服务(取决于它们各自的DAO)和它自己的DAO，则为合理嵌套的对象生成when-thenReturn子句会很费力，并且开发人员被视为走了简单的路并加载整个spring上下文并从直接来源获取其数据，这些来源可能并不总是能提供可以遍历所有必需代码路径的数据.以此为背景，我的一位同事建议为什么不运行示例集成测试，并使用方面捕获所有相关数据点并将其序列化为XML表示形式，该表示形式可用于实现单元测试的测试数据案件.令我们惊喜的是，我们在github上找到了一个名为 TestDataCaptureJ 的框架，该框架与此非常相似.它使用方面捕获数据点，并生成Java代码来创建对象.

When mocking dependent services for writing unit test cases for any enterprise-grade java service, I find setting up the data for the unit test cases a huge pain. Most of the times, this is the single most compelling reason for developers to not write unit test cases and rather write integration style test cases. If the service is dependent on couple of other services (which depend on their respective DAO's) and a DAO of its own, generating the when-thenReturn clauses for a reasonably nested object becomes quite an effort and developers are seen to be taking the easy route and loading the entire spring context and sourcing their data from the direct sources which may not always give the data that can traverse all required code paths. With this in the background, a colleague of mine suggested that why not run a sample integration test, and using aspects, capture all of the relevant data points and serialize it to an XML representation which may be used for materializing test data for the unit test cases. To our pleasant surprise we found a framework called TestDataCaptureJ on github which was very similar to this. It used aspects to capture the data points and it generated the java code to create the objects.

网站上所述的动机似乎很贴切，我想知道是否还有其他替代方法可以提供类似的功能.同样，如果专家们可以批评这种整体方法，那就太好了.

The motivation stated on the site seemed very apt and I was wondering if there are any other alternatives that can give similar features. Also, it would be great if the experts can critique this overall approach.

此外，该项目已有2年的历史，并且存在一些我们必须修复的错误，并希望将其作为经过复习的github派发回来.只需检查一下，以确保没有其他知名马similar提供的其他类似建议.

Also, the project is about 2 yrs old and has a few bugs which we we had to fix and are hoping to give it back as a mavenized github fork. Just checking to ensure that there is no other similar initiative from one of the well-known stables as well.

提前谢谢！

推荐答案

对于这种方法，我有两个批评 ...，请记住，我对您所处环境的了解几乎为零，意味着我在这里建议的内容可能对您不起作用.

I have two critiques to that approach... and please bear in mind that my knowledge of your context is almost nil, which means that what I suggest here might not work for you.

我只遇到过一个您提到的问题，而且这是一个症状，对象之间的耦合过多，因为责任方法是广泛的.从那时起，我使用了域驱动设计的方法，但是我再也没有这个问题了

I've only once experienced a problem like the one you mentioned, and it was a symptom that there was too much coupling between the objects because the responsbilities were way to broad. Since then I use a Domain-Driven Design approach and I haven't had this problem again.

我更喜欢使用测试数据生成器来创建测试数据.这种方法使我可以拥有自己想要构建的模板，而只需替换我对测试感兴趣的部分即可.如果您决定采用这种方式，强烈建议您使用一个名为 Make-轻松简化了这些构建器的创建.

I prefer to use Test-Data Builders to create test data. This approach allows me to have a template of what I want to build, and just replace the bits I'm interested in the test. If you decide to go this way, I strongly suggest you to use a tiny library called Make-It-Easy that simplifies the creation of these builders.

如果有时间，我建议您

1. 观看迈克尔·费瑟斯(Michael Feathers)称为可测试性与良好设计之间的深刻协同作用的预设与您所经历的非常相似.
2. 阅读这本书通过测试引导对象增长的系统(又名GOOS)，它对如何编写简单，出色，可测试的代码具有各种见解.

1. Watch a presetation called The Deep Synergy Between Testability and Good Design by Michael Feathers - Part of the talk is about something very similar to what you're experiencing.
2. Read the book Growing Object-Orieted Systems, Guided by Tests (aka GOOS), it has all sorts of insights about how to write simple, amazing, testable code.

这篇关于为嵌套对象的单元测试用例生成测试数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！