如何进行单元测试的情况下,有两个公共方法,一个调用另一个?
当有两个公用方法和一个方法在同一个类中调用另一个公用方法时,测试方法的方法是什么?如何进行单元测试的情况下,有两个公共方法,一个调用另一个?
我应该如何在这种情况下编写单元测试?
一个例子
class SpecificIntMath {
public int add(int a,int b) {
return a+b;
}
public int multiply(int a, int b) {
int mul = 0;
for(int i = 0;i<b,i++) {
mul=add(a,mul);
}
return mul;
}
}
这个例子没有显示的两个参与的方法,但这个概念的复杂性。
我应该分别测试add
和multiply
吗?如果我只测试multiply
,我觉得我们错过了multiple
无法提供参数的情况。
假设multiply
和add
需要单独测试,我应该能够模拟add
?这怎么可能?
假设multiply
和add
要单独测试,我不应该模拟,我应该让add
照原样运行。如果是这种情况,我应该如何处理add
中的程序流程?
什么是测试这种情况的方法。
编辑1:
在下面的代码,
class MCVC {
public boolean getWhereFrom(List<User> users) {
boolean allDone = true;
for(User user: users){
String url = user.getUrl();
switch(url) {
case Consts.GOOGLE:
someDao.updateFromAddr(user);
user.setEntry("Search Engine");
break;
case Consts.FACEBOOK:
someDao.updateFromAddr(user);
user.setEntry("Social Media");
break;
case Consts.HOME:
someDao.updateToAddr(user);
user.setEntry("Company");
default
user.setEntry(null);
allDone = false;
break;
}
}
return allDone;
}
public void likedDeck() {
List<Users> usersList = deckDao.getPotentialUsers(345L,HttpStatus.OK);
boolean flag = getWhereFrom(usersList);
if(flag) {
for(User user: usersList) {
//some Action
}
}
}
}
我应该考虑getWhereFrom()
在测试likedDeck()
或者我应该承担任何违约的情况呢?如果我考虑违约情况,那么在输出不是违约的情况下,我就会失败。我不确定我应该嘲笑它,因为正在调用的课程正在测试中。 Spying/Mocking class under test
你不在乎。
您可以使用单元测试来测试合同自身各公共方法的。因此,你写测试,确保add()
和multiply()
做他们应该做的。
内部使用另一个的事实在外面没有兴趣。您的测试不应该知道也不关心这个内部实现细节。
只是为了记录:因为你的代码是现在写的;你绝对不要在这里嘲笑。这里不需要嘲笑;只有增加测试的东西有没有与您的真实生产代码有关的风险。您只有只有当您必须控制对象的各个方面以启用测试时才使用模拟。但是您的示例代码中没有任何内容需要嘲笑测试。如果会的话 - 这将是一个糟糕的设计/实施(鉴于这些方法的合同)!
编辑;给出的变化示例中的问题:
首先,有一个错误在getWhereFrom()
- 你迭代一个列表;但是你一直覆盖该列表中的返回值。所以当第一次迭代将结果设置为false时,该信息可能在下一个循环中丢失。
我看到的实际问题两种选择:
- 你转的Mockito;和它的“间谍”概念做部分嘲弄;如果你想保持你的源代码是
- 我,亲自;我宁愿投入时间来改进生产代码。在我看来作为
getWhereFrom()
可能是值得其自己类(在那里我可能不会拥有它的用户的名单上工作,但只是一个用户;也有返回一个布尔值可以帮助;-) 。当你这样做时,你可以使用依赖注入来获取该“WhereFromService”类的(模拟)实例。
换句话说:您显示的代码可以重新编制/重构;例如更清楚地遵循SRP。但这当然是一项更大的任务;你需要与周围的人讨论。
好吧,如果我分别测试两个数据,那我该如何处理'multiply'内的数据[在我的情况下,我必须模拟某些'Dao'],其输出直接影响“add”的内部? –
我用DI来推动模拟。问题在于Dao的输出是一个列表,而'add''方法有一个'switch-case'和更多的'Dao'影响某些状态,我必须测试它们的参数。每个模拟都是依赖注入的。 –
清除了错误。 –
至少测试他们两个。乘法测试隐式地测试添加是没有问题的。在大多数情况下,您应该问自己是否有必要公开两种方法。
我应该分别测试加法和乘法吗?
如果您正在进行单元测试,您应该单独测试它们。您只想在进行组件或集成测试时一起测试它们。
假设乘法加上单独测试,我应该能够 模拟添加吗?
是
这怎么可能?
使用mockito或任何其他嘲讽框架。究竟如何才能看到这里Use Mockito to mock some methods but not others
假设乘法和加法单独测试,我不应该 模拟,我应该让加执行,因为它是。
我不会这么做。添加的内部变化可能会影响测试的乘法运算,并且测试会变得更加复杂和不稳定。
只是单独测试它们。当测试'multiply'时,不要试图模拟'add',你甚至不知道'multiply'是否会调用'add'(至少在编写测试时你不应该知道这一点)。 – john16384
另外请注意,当b 2017-04-06 11:36:57