使用 jUnit 进行数据驱动测试
您使用什么在 jUnit 中编写数据驱动测试？
（我的定义）数据驱动测试是一种从某些外部源（文件、数据库等）读取数据的测试，每行/文件/任何内容执行一个测试，并在测试运行程序中显示结果，就像您进行了单独的测试 - 每次运行的结果都是单独显示的，而不是显示在一个巨大的集合中。
What do you use for writing data-driven tests in jUnit?
(My definition of) a data-driven test is a test that reads data from some external source (file, database, ...), executes one test per line/file/whatever, and displays the results in a test runner as if you had separate tests - the result of each run is displayed separately, not in one huge aggregate.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
在 JUnit4 中，您可以使用 参数化 测试运行程序来执行数据驱动测试。
它没有很好的文档记录，但基本思想是创建一个返回对象数组集合的静态方法（用
@Parameters注释）。这些数组中的每一个都用作测试类构造函数的参数，然后可以使用构造函数中设置的字段来运行常用的测试方法。您可以在 @Parameters 方法中编写代码来读取和解析外部文本文件（或从另一个外部源获取数据），然后您可以通过编辑此文件来添加新测试，而无需重新编译测试。
In JUnit4 you can use the Parameterized testrunner to do data driven tests.
It's not terribly well documented, but the basic idea is to create a static method (annotated with
@Parameters) that returns a Collection of Object arrays. Each of these arrays are used as the arguments for the test class constructor, and then the usual test methods can be run using fields set in the constructor.You can write code to read and parse an external text file in the
@Parametersmethod (or get data from another external source), and then you'd be able to add new tests by editing this file without recompiling the tests.这就是 TestNG 及其
@DataSource的闪光点。这就是我更喜欢它而不是 JUnit 的原因之一。其他是依赖性和并行线程测试。This is where TestNG, with its
@DataSource, shines. That's one reason why I prefer it toJUnit. The others are dependencies and parallel threaded tests.我使用内存数据库，例如 hsqldb，这样我就可以使用“生产风格”预填充数据库“数据集，或者我可以从一个空的 hsqldb 数据库开始，并用执行测试所需的行填充它。最重要的是，我将使用 JUnit 和 Mockito。
I use an in-memory database such as hsqldb so that I can either pre-populate the database with a "production-style" set of data or I can start with an empty hsqldb database and populate it with rows that I need to perform my testing. On top of that I will write my tests using JUnit and Mockito.
我使用 dbUnit、jMock 和 jUnit 4。然后您可以将其作为套件或单独运行
I use combination of dbUnit, jMock and jUnit 4. Then you can ether run it as suite or separately
您最好使用适合您需求的
DataDrivenTestCase来扩展TestCase。这是工作示例：
http://mrlalonde.blogspot.ca/2012/ 08/data-driven-tests-with-junit.html
与参数化测试不同，它允许良好命名的测试用例。
You are better off extending
TestCasewith aDataDrivenTestCasethat suits your needs.Here is working example:
http://mrlalonde.blogspot.ca/2012/08/data-driven-tests-with-junit.html
Unlike parameterized tests, it allows for nicely named test cases.
我使用@DroidIn.net，这正是我正在做的事情，但是要从字面上回答您的问题“并在测试运行程序中显示结果，就像您进行单独的测试一样”，您必须查看 JUnit4 参数化运行程序。 DBUnit 不这样做。如果你必须做很多这样的事情，老实说 TestNG 更灵活，但你绝对可以在 JUnit 中完成它。
您还可以查看 JUnit Theories 运行器，但我记得它对于数据驱动的数据集来说不太好，这是有道理的，因为 JUnit 不涉及处理大量外部数据。
I'm with @DroidIn.net, that is exactly what I am doing, however to answer your question literally "and displays the results in a test runner as if you had separate tests," you have to look at the JUnit4 Parameterized runner. DBUnit doesn't do that. If you have to do a lot of this, honestly TestNG is more flexible, but you can absolutely get it done in JUnit.
You can also look at the JUnit Theories runner, but my recollection is that it isn't great for data driven datasets, which kind of makes sense because JUnit isn't about working with large amounts of external data.
尽管这是一个相当老的话题，但我仍然想贡献自己的一份力量。
我觉得 JUnit 对数据驱动测试的支持太少而且太不友好。例如。为了使用参数化，我们需要编写构造函数。使用 Theories runner，我们无法控制传递给测试方法的测试数据集。
本博客文章系列中还指出了更多缺点： http ://www.kumaranuj.com/2012/08/junits-parameterized-runner-and-data.html
现在有一个以 EasyTest 形式很好地出现的全面解决方案，它是一个扩展自的框架JUnit 旨在为其用户提供许多功能。它的主要重点是使用 JUnit 执行数据驱动测试，尽管您不再需要实际依赖 JUnit。这是可供参考的github项目： https://github.com/anujgandharv/easytest
如果有人感兴趣贡献他们的想法/代码/建议，那么现在就是时候了。您只需转到 github 存储库并创建问题即可。
Even though this is quite an old topic, i still thought of contributing my share.
I feel JUnit's support for data driven testing is to less and too unfriendly. for eg. in order to use parameterized, we need to write our constructor. With Theories runner we do not have control over the set of test data that is passed to the test method.
There are more drawbacks as identified in this blog post series: http://www.kumaranuj.com/2012/08/junits-parameterized-runner-and-data.html
There is now a comprehensive solution coming along pretty nicely in the form of EasyTest which is a a framework extended out of JUnit and is meant to give a lot of functionality to its users. Its primary focus is to perform Data Driven Testing using JUnit, although you are not required to actually depend on JUnit anymore. Here is the github project for refernece: https://github.com/anujgandharv/easytest
If anyone is interested in contributing their thoughts/code/suggestions then this is the time. You can simply go to the github repository and create issues.
通常，数据驱动测试使用小型可测试组件来处理数据。 （文件读取对象，或模拟对象）对于数据库和应用程序之外的资源，模拟用于模拟其他系统。 （网络服务和数据库等）。通常我看到的是有处理数据和输出的外部数据文件。这样就可以将数据文件添加到 VCS 中。
Typically data driven tests use a small testable component to handle the data. (File reading object, or mock objects) For databases, and resources outside of the application mocks are used to similate other systems. (Web services, and databases etc). Typically I see is that there are external data files that handle the data and the output. This way the data file can be added to the VCS.
我们目前有一个 props 文件，其中包含我们的 ID 号。这是非常脆弱的，但是很容易让一些东西运转起来。我们的计划是最初让这些 ID 号可以被我们的 ant 构建中的 -D 属性覆盖。
我们的环境使用旧数据库，其中数据严重交织，在运行之前无法加载（例如通过 dbUnit）。最终我们希望到达单元测试查询数据库以查找具有被测属性的 ID 的位置，然后在单元测试中使用该 ID。它会很慢，并且更恰当地称为集成测试，而不是“单元测试”，但我们将针对真实数据进行测试，以避免我们的应用程序针对测试数据完美运行但针对真实数据失败的情况。
We currently have a props file with our ID numbers in it. This is horribly brittle, but is easy to get something going. Our plan is to initially have these ID numbers overridable by -D properties in our ant builds.
Our environment uses a legacy DB with horribly intertwined data that is not loadable before a run (e.g. by dbUnit). Eventually we would like to get to where a unit test would query the DB to find an ID with the property under test, then use that ID in the unit test. It would be slow and is more properly called integration testing, not "unit testing", but we would be testing against real data to avoid the situation where our app runs perfectly against test data but fails with real data.
一些测试将有助于接口驱动。
如果数据库/文件读取是通过接口调用检索的，那么只需让单元测试实现该接口，单元测试类就可以返回您想要的任何数据。
Some tests will lend themselves to being interface driven.
If the database/file reads are retrieved by an interface call then simply get your unit test to implement the interface and the unit test class can return whatever data you want.