您是否建议在 @Test 方法中对测试用例进行任何分组,或者每个测试场景使用一个 @Test 方法?例如,假设有不同的方法可以在应用程序中设置上下文。
下面的想法可以接受吗?
@Test
public void testContextSetting() {
// Test default setting
assert(...)
// Test setting a context variable
assert(...)
...
}
或者,您更愿意建议这样,让每个方法尽可能原子:
@Test
public void textDefaultSetting() {
// Test default setting
assert(...)
}
@Test
public void testSettingContextVar() {
// Test setting a context variable
assert(...)
...
}
如有任何反馈,我们将不胜感激。
最佳答案
我更喜欢每个方法都有一个测试用例。
首先,如果将它们拆分为方法,则更容易查看正在测试的案例,而不是查找嵌入在代码中的注释。大多数 IDE 会给你一个方法的总结,所以不要说“我测试了边缘情况 XYZ 吗?”然后寻找评论,或寻找设置边缘情况的代码,您只需寻找名为 setupContextEdgeCaseXYZ()
的方法。
第二个原因是,如果您有多个案例,其中一个可能会失败,而其他的则永远不会执行。
testDefaultCase()
testInvalidInput()
testEdgeCase1()
testEdgeCase2()
使用这种结构,可以更容易地确定输入检查错误并且边缘情况 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);
}
通过拆分案例,您可以避免上述错误,因为这会变成编译错误或警告。
关于java - 在同一测试用例或单独的测试用例中测试默认值和 setter ,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/6252187/