gpt4 book ai didi

java - 在同一测试用例或单独的测试用例中测试默认值和 setter

转载 作者:IT老高 更新时间:2023-10-28 20:46:53 28 4
gpt4 key购买 nike

您是否建议在 @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/

28 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com