最近,JUnit添加了Theories的新概念(自v4.4起)。
简而言之,您可以使用@Theory
注释(而不是@Test
)标记测试方法,使测试方法参数化并声明一个参数数组,标记为@DataPoints
注释在同一个班级的某个地方。
JUnit将依次运行参数化测试方法,逐个传递从@DataPoints
检索到的参数。但只有在第一次这样的调用失败时(由于任何原因)。
这个概念似乎与TestNG的@DataProviders
非常相似,但是当我们使用数据提供程序时,所有场景都会在执行结果的情况下运行。它很有用,因为你可以看到有多少有趣的工作/不工作,你可以更有效地修复你的程序。
所以,我想知道为每个@Theory
执行@DataPoint
标记方法的原因是什么? (从Theories运动员那里继承并制造一个可以忽略失败的自定义跑步者似乎并不那么困难,但为什么我们不能开箱即用?)
UPD :我创建了一个容错版本的Theories runner,并将其公开访问:https://github.com/rgorodischer/fault-tolerant-theories
为了将它与标准的Theories运行器进行比较,运行StandardTheoriesBehaviorDemo,然后将FaultTolerantTheoriesBehaviorDemo放在src/test/...
文件夹下。
答案 0 :(得分:3)
在单个测试中报告多个故障通常表明这一点 与单元测试应该做的相比,测试做得太多了。 通常这意味着测试确实是一个 功能/验收/客户测试,或者,如果是单元测试,那么它 是一个太大的单元测试。
JUnit旨在通过一系列小型测试获得最佳效果。它 在测试类的单独实例中执行每个测试。它 报告每次测试失败。共享设置代码是最自然的 测试之间共享。这是一个贯穿JUnit的设计决策, 当你决定每次测试报告多次失败时,你就会开始 与JUnit作斗争。不建议这样做。
长时间的测试是一种设计气味,表明设计的可能性 问题。 Kent Beck喜欢在这种情况下说“有一个 有机会了解你的设计。“我们愿意 看到模式语言围绕这些问题发展,但事实并非如此 但是写下来了。 资料来源:http://junit.sourceforge.net/doc/faq/faq.htm#tests_12
要忽略断言失败,您还可以使用JUnit错误收集器规则:
ErrorCollector规则允许执行测试后继续 找到第一个问题(例如,收集所有不正确的问题 表中的行,并一次报告所有行
例如,您可以编写这样的测试。
public static class UsesErrorCollectorTwice {
@Rule
public ErrorCollector collector= new ErrorCollector();
@Test
public void example() {
String x = [..]
collector.checkThat(x, not(containsString("a")));
collector.checkThat(y, containsString("b"));
}
}
错误收集器使用hamcrest Matchers。根据您的喜好,这是积极的与否。
答案 1 :(得分:1)
AFAIK,这个想法与断言相同,第一次失败就会停止测试。这是参数化和放大器之间的区别。的理论。
参数化采用一组数据点,并为每个数据点运行一组测试方法。理论也是这样,但是当第一个断言失败时失败。
尝试查看Parameterized。也许它提供了你想要的东西。
答案 2 :(得分:0)
根据理论的定义,如果理论中的单个测试是错误的,那么理论是错误的。如果您的测试用例不遵循此规则,则称其为“理论”是错误的。