在JUnit中记录导致错误的数据的推荐方法是什么?

时间:2009-02-14 16:39:26

标签: java unit-testing logging junit

我对JUnit比较陌生,今天我正在编写一些我的第一个测试。对于某些特定方法,我想传递随机值(所有这些都在正确的范围内)。如果该方法因任何原因失败,我想知道哪个值导致它失败。那么建议的方法是什么?

(或者在JUnit测试中使用随机值是不是很糟糕?)

7 个答案:

答案 0 :(得分:3)

如果您确实想使用随机值,那么只需将值用于断言方法的文本部分即可。然后,如果断言被断言,则输入值将存在,您可以调查它出现问题的原因。

这是Fuzz Testing并且是一项功能强大的技术,但在拥有可用的源代码或测试具有复杂内部状态和多次交互的系统时最有用。< / p>

更有用的测试类型可能是white box testing,其中有意选择测试输入以涵盖您可能获得的各种输入类型。 JTest似乎是java中的自动化工具。 MS Research为c#提供了PEX

如果手动完成,只需使用覆盖工具并验证覆盖相关路径通常就足够了,尽管自动化工具提供的边界情况通常具有指导意义。

答案 1 :(得分:2)

您可以尝试使用:http://www.openfuture.de/Log4Unit/进行日志记录,我建议不要使用单元测试的随机值,因为它们应该重复。如果你想测试很多值,只需使用for循环和对索引值的一些修改,这很容易重复。

如果你考虑一下,实际上并没有使用随机值比“硬编码”更有利的情况。如果你想要在一个值范围内进行良好的传播,你可以使用一个函数或使用带有固定种子的随机值(以获得相同的数字)。

如果测试失败,您希望能够修复它并再次运行测试。这就是单元测试中随机数的问题。

答案 2 :(得分:2)

只需在断言的“诊断消息”参数中报告实际值和期望值。这是JUnit测试的常见做法,“助手”断言方法默认情况下会这样做,例如: assertEquals会说“预期6并得到7”。

随机值是可以的,只要您可以确保随机范围构成被测代码的等价类

答案 3 :(得分:2)

您是否尝试使用属于JUnit 4.4+的'assertThat'方法和Hamcrest Matchers?查看README [1]并搜索“assertThat”。

我已经非常喜欢代码的更多语义外观,而失败消息的信息量更大。

[1] http://junit.sourceforge.net/README.html

答案 4 :(得分:1)

我建议parameterized test cases。所以你可以使用随机值(在数据方法中)并在跑步者中“记录”它,如果任何方法都会失败。

答案 5 :(得分:0)

如果您的单元测试因任何原因失败,您将在测试运行中看到红色交通信号灯。测试运行器还将显示哪个测试方法失败,测试运行器的日志报告更多详细信息(例如,转储堆栈跟踪)。调查该错误,纠正错误,并且测试永远不会再次失败,除非您破坏代码。

因此,我没有看到记录异常的必要性。您应该立即修复任何错误(红色红绿灯)

如果您无法保证生成这些值没有错误,则使用随机值可能非常危险。检查边界条件可能更有用。

答案 6 :(得分:0)

通过为随机数生成器提供常量种子,可以获得可重复的随机值。在Java中创建一个带有固定的java的java.util.Random,并将其作为构造函数参数传递给类(依赖注入)。像这样:

new ClassUnderTest(new Random(123L));

根据您正在测试的内容,您还可以将随机值的生成与其使用分开。如果您的类X具有从1到10的随机值,那么您可以通过传递边缘值1和10以及中间的某些值(例如4)来测试它。然后您需要对那些生产者进行另一个测试随机值。例如,给它一个带有固定种子的java.util.Random并生成100个值,并检查它们是否都在允许的范围内。