blocks|key|563046|text|在JUnit4中，您可以使用Parameterized测试运行程序来执行数据驱动测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|563047|它没有很好的文档，但基本思想是创建一个返回对象数组集合的静态方法(用@Parameters注释)。这些数组中的每个数组都用作测试类构造函数的参数，然后可以使用构造函数中设置的字段来运行常用的测试方法。|style|CODE|563048|您可以编写代码来读取和解析@Parameters方法中的外部文本文件(或从另一个外部源获取数据)，然后可以通过编辑此文件来添加新测试，而无需重新编译测试。|563049|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/junit-team/junit/wiki/Parameterized-tests^0|E|D|0|0|Y|B|0|D|B|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@$A|W|B|X|F|G]]|9|@]|C|$]]|$1|H|3|I|5|6|7|Y|8|@$A|Z|B|10|F|G]]|9|@]|C|$]]|$1|J|3|-4|5|6|7|11|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]]]

In JUnit4 you can use the <a href="https://github.com/junit-team/junit/wiki/Parameterized-tests" rel="noreferrer">Parameterized</a> testrunner to do data driven tests.

It's not terribly well documented, but the basic idea is to create a static method (annotated with <code>@Parameters</code>) 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 <code>@Parameters</code> method (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.

blocks|key|563133|text|这就是拥有@DataSource的TestNG大放异彩的地方。这就是为什么我更喜欢它而不是JUnit的原因。其他的是依赖和并行线程测试。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|563134|entityMap^0|5|B|19|5|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

This is where TestNG, with its <code>@DataSource</code>, shines. That's one reason why I prefer it to <code>JUnit</code>. The others are dependencies and parallel threaded tests.

blocks|key|563061|text|我使用内存中的数据库，比如hsqldb，这样我就可以用“生产风格”的数据集预先填充数据库，也可以从一个空的hsqldb数据库开始，然后用执行测试所需的行来填充它。最重要的是，我将使用JUnit和Mockito编写测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|563062|entityMap|0|LINK|mutability|MUTABLE|url|http://hsqldb.org/|1|http://www.junit.org/|2|http://code.google.com/p/mockito/^0|D|6|0|2J|5|1|2P|7|2|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]|$A|T|B|U|1|V]|$A|W|B|X|1|Y]]|C|$]]|$1|D|3|-4|5|6|7|Z|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]|N|$5|G|H|I|C|$J|O]]]]

I use an in-memory database such as <a href="http://hsqldb.org/" rel="noreferrer">hsqldb</a> 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 <a href="http://www.junit.org/" rel="noreferrer">JUnit</a> and <a href="http://code.google.com/p/mockito/" rel="noreferrer">Mockito</a>.

blocks|key|562992|text|我使用的是dbUnit、jMock和jUnit+4的组合，这样你就可以将它作为套件或者单独运行|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|562993|entityMap|0|LINK|mutability|MUTABLE|url|http://www.dbunit.org/howto.html|1|http://www.jmock.org/^0|5|6|0|C|5|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

I use combination of <a href="http://www.dbunit.org/howto.html" rel="nofollow noreferrer">dbUnit</a>, <a href="http://www.jmock.org/" rel="nofollow noreferrer">jMock</a> and jUnit 4. Then you can ether run it as suite or separately

blocks|key|563169|text|最好使用适合您需要的DataDrivenTestCase来扩展TestCase。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|563170|下面是一个工作示例：http://mrlalonde.blogspot.ca/2012/08/data-driven-tests-with-junit.html|563171|与参数化测试不同，它支持命名良好的测试用例。|563172|entityMap|0|LINK|mutability|MUTABLE|url|http://mrlalonde.blogspot.ca/2012/08/data-driven-tests-with-junit.html^0|A|I|V|8|0|A|1Y|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]|$9|U|A|V|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|W|8|@]|D|@$9|X|A|Y|1|Z]]|E|$]]|$1|H|3|I|5|6|7|10|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|11|8|@]|D|@]|E|$]]]|K|$L|$5|M|N|O|E|$P|Q]]]]

You are better off extending <code>TestCase</code> with a <code>DataDrivenTestCase</code> that suits your needs.
Here is working example:
<a href="http://mrlalonde.blogspot.ca/2012/08/data-driven-tests-with-junit.html" rel="nofollow noreferrer">http://mrlalonde.blogspot.ca/2012/08/data-driven-tests-with-junit.html</a>
Unlike parameterized tests, it allows for nicely named test cases.

blocks|key|593513|text|我支持@DroidIn.net，这正是我正在做的，然而，要从字面上回答您的问题“并在测试运行器中显示结果，就像您有单独的测试一样”，您必须查看JUnit4参数化运行器。DBUnit不会这样做。如果你必须做很多这样的事情，老实说，TestNG更灵活，但你绝对可以在JUnit中完成。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|593514|您还可以查看JUnit理论运行器，但我记得它对于数据驱动的数据集来说并不是很好，这在某种程度上是有意义的，因为JUnit不是关于处理大量外部数据的。|593515|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

blocks|key|593568|text|尽管这是一个相当古老的话题，但我仍然想贡献自己的一份力量。我觉得JUnit对数据驱动测试的支持太少，太不友好了。例如。为了使用参数化，我们需要编写我们的构造函数。使用理论运行器，我们无法控制传递给测试方法的测试数据集。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|593569|在这篇博客文章系列中发现了更多的缺点：http://www.kumaranuj.com/2012/08/junits-parameterized-runner-and-data.html|offset|length|593570|现在有了一个全面的解决方案，它很好地以EasyTest的形式出现，这是一个从JUnit扩展出来的框架，旨在为用户提供许多功能。它的主要关注点是使用JUnit执行数据驱动测试，尽管您不再需要实际依赖于JUnit。这里是github项目供参考：https://github.com/anujgandharv/easytest|593571|如果任何人有兴趣贡献他们的想法/代码/建议，那么现在就是时候了。您可以简单地转到github存储库并创建问题。|593572|entityMap|0|LINK|mutability|MUTABLE|url|http://www.kumaranuj.com/2012/08/junits-parameterized-runner-and-data.html|1|https://github.com/anujgandharv/easytest^0|0|J|22|0|0|3C|14|1|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@$D|V|E|W|1|X]]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@$D|Z|E|10|1|11]]|A|$]]|$1|H|3|I|5|6|7|12|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]|R|$5|M|N|O|A|$P|S]]]]

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: <a href="http://www.kumaranuj.com/2012/08/junits-parameterized-runner-and-data.html" rel="nofollow">http://www.kumaranuj.com/2012/08/junits-parameterized-runner-and-data.html</a>

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: <a href="https://github.com/anujgandharv/easytest" rel="nofollow">https://github.com/anujgandharv/easytest</a>

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.

blocks|key|2001063|text|通常，数据驱动测试使用一个小型的可测试组件来处理数据。(文件读取对象，或模拟对象)用于数据库，应用程序模拟之外的资源用于模拟其他系统。(Web服务和数据库等)。我通常看到的是，有处理数据和输出的外部数据文件。这样就可以将数据文件添加到VCS中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2001064|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|1865748|text|我们目前有一个道具文件，里面有我们的ID号。这是非常脆弱的，但很容易让事情继续下去。我们的计划是最初让这些ID号在我们的ant构建中被-D属性覆盖。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1865749|我们的环境使用了一个遗留的DB，它的数据交织在一起，在运行之前是无法加载的(例如通过dbUnit)。最终，我们希望到达单元测试将查询DB以查找带有被测属性的ID的位置，然后在单元测试中使用该ID。这将是缓慢的，更恰当的说法是集成测试，而不是“单元测试”，但我们将针对真实数据进行测试，以避免我们的应用程序在测试数据上运行良好，但在真实数据下失败的情况。|1865750|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

blocks|key|1863419|text|一些测试将适合于由接口驱动。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1863420|如果数据库/文件读取是通过接口调用来检索的，那么只需让单元测试实现该接口，单元测试类就可以返回您想要的任何数据。|1863421|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

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.

Data-driven tests with jUnit

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

在jUnit中使用什么来编写数据驱动测试？(我的定义是)数据驱动测试是一种测试，它从一些外部源(文件、数据库等)读取数据，每行/文件/任何东西执行一个测试，并在测试运行器中显示结果，就像您有单独的测试一样-每次运行的结果都是单独显示的，而不是在一个巨大的聚合中。

问使用jUnit进行数据驱动测试
EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问使用jUnit进行数据驱动测试EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问使用jUnit进行数据驱动测试
EN