Ari*_*iod 40 java testing junit4
您是否建议在@Test方法中进行任何测试用例分组,或者每个测试方案都有一个@Test方法?例如,假设有不同的方法在应用程序中设置上下文.
以下想法是否可以接受?
@Test
public void testContextSetting() {
// Test default setting
assert(...)
// Test setting a context variable
assert(...)
...
}
Run Code Online (Sandbox Code Playgroud)
或者,您是否愿意建议像这样,让每个方法尽可能原子化:
@Test
public void textDefaultSetting() {
// Test default setting
assert(...)
}
@Test
public void testSettingContextVar() {
// Test setting a context variable
assert(...)
...
}
Run Code Online (Sandbox Code Playgroud)
对于任何反馈,我们都表示感谢.
M. *_*sup 34
我更喜欢每种方法有一个测试用例.
首先,如果将它们分成方法而不是查找代码中嵌入的注释,则更容易看到正在测试的案例.大多数IDE都会给你一个方法摘要,所以不要说"我测试过edgecase XYZ吗?" 然后寻找一个注释,或者寻找设置该edgecase的代码,你只需要查找名为的方法setupContextEdgeCaseXYZ().
第二个原因是如果你有多个案例,一个可能会失败,然后其他人永远不会执行.
testDefaultCase()
testInvalidInput()
testEdgeCase1()
testEdgeCase2()
Run Code Online (Sandbox Code Playgroud)
使用这种结构,可以更容易地确定输入检查是错误的并且边缘情况2被不正确地处理,但是其他情况都是正常的(并且您可能发现两个失败的情况是相关的并且问题被更快地诊断).
第三个原因是您可能会意外地保留先前测试集中的值,这些值会以不显眼的方式使后一测试无效.一个简单的例子:
@Test
public void testMyMethod() {
//test default
String test = Foo.bar(null);
assertEquals("foo", test);
//test case 1
Foo.bar(aValue);
//Oops forgot to set value above, this passes regardless of
//what the above call does
assertEquals("foo", test);
}
Run Code Online (Sandbox Code Playgroud)
通过将案例分开,您可以避免上述错误,因为这会导致编译错误或警告.
RMT*_*RMT 11
最佳实践是每种方法有一个测试用例.方法名称描述了您正在执行的测试.当测试失败时,只需一个断言就可以更容易地进行调试.
| 归档时间: |
|
| 查看次数: |
17394 次 |
| 最近记录: |