【问题标题】:How to unit test to the case where there are two public methods, one calling another?如何对有两个公共方法,一个调用另一个的情况进行单元测试?
【发布时间】:2017-04-07 15:06:25
【问题描述】:

当有两个公共方法并且一个方法调用同一个类中的另一个公共方法时,如何测试方法?

在这种情况下我应该如何编写单元测试?


一个例子

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;
   }
}

这个例子并没有展示所涉及的两种方法的复杂性,而是展示了概念。

我应该分别测试addmultiply 吗?如果我只测试multiply,我觉得我们错过了multiple 无法提供参数的情况。

假设 multiplyadd 分别测试,我应该能够模拟 add 吗?这怎么可能?

假设 multiplyadd 分别进行测试并且我不应该模拟,我应该让 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
            }
        }
    }
}

在测试likedDeck() 时我应该考虑getWhereFrom() 还是应该假设任何默认情况?如果我考虑默认情况,我会输掉输出不是默认情况的情况。我不确定我应该嘲笑它,因为正在测试正在调用的课程。 Spying/Mocking class under test

【问题讨论】:

  • 单独测试它们。不要在测试multiply时尝试模拟add,你甚至不知道multiply是否会调用add(至少在编写测试时你不应该知道这一点)。
  • 另请注意,当 b 时,您的乘法将被破坏

标签: java unit-testing junit mockito


【解决方案1】:

你不在乎。

您使用单元测试来单独测试 each 公共方法的 contract。因此,您编写的测试可以确保 add()multiply() 都执行它们应该执行的操作。

一个人在内部使用另一个人这一事实在外部是不感兴趣的。您的测试不应该知道也不应该关心这个内部实现细节。

仅作记录:因为您的代码是现在编写的;你绝对不要在这里嘲笑。这里不需要模拟;并且只会增加测试与您的实际生产代码无关的东西的风险。您在必须控制对象的各个方面以启用测试的情况下使用模拟。但是您的示例代码中没有任何内容需要模拟来进行测试。如果它会 - 这将表明设计/实施不佳(鉴于这些方法的合同)!

编辑;鉴于问题中的更改示例:

首先,getWhereFrom() 中有一个bug——你迭代了一个列表;但是您不断覆盖该列表中的返回值。因此,当第一次迭代将结果设置为 false 时;该信息可能会在下一个循环中丢失。

我看到实际问题的两个选项:

  • 你转向 Mockito;及其“间谍”概念进行部分嘲笑;如果您想保持源代码不变
  • 我个人;我宁愿花时间改进生产代码。在我看来,getWhereFrom() 可能值得拥有它的 自己的 类(我可能不会让它在 list 用户上工作;但只有 一个 用户;这也有助于返回单个布尔值 ;-)。当您这样做时,您可以使用依赖注入来获取该“WhereFromService”类的(模拟)实例。

换句话说:您展示的代码可能会被重新设计/重构;例如更清楚地遵循SRP。但这当然是一项更大的任务。您需要与周围的人讨论。

【讨论】:

  • 好的,如果我分别测试两者,那么我如何操作multiply 内部的数据[在我的情况下,我必须模拟某些Dao] 其输出直接影响@987654328 的内部@?
  • 我已经使用 DI 来推送 mock。问题是 Dao 的输出是一个列表,而“add”方法有一个switch-case 和更多Dao,它们会影响某些状态,我必须测试它们的参数。每个 Mock 都是依赖注入的。
  • 清除了这个错误。
【解决方案2】:

至少分别测试它们。乘法测试隐式地测试加法是没有问题的。在大多数情况下,您应该问自己是否有必要公开这两种方法。

【讨论】:

    【解决方案3】:

    我应该分别测试加法和乘法吗?

    如果您进行单元测试,您应该单独测试它们。您只想在进行组件或集成测试时一起测试它们。

    假设乘法和加法分别进行测试,我应该能够 模拟添加?

    是的

    这怎么可能?

    使用 mockito 或任何其他模拟框架。具体怎么看这里Use Mockito to mock some methods but not others

    假设乘法和加法分别进行测试,我不应该 mock,我应该让 add 照原样执行吗?

    我不会那样做。 add 的内部更改可能会影响乘法测试,并且您的测试会变得更加复杂和不稳定。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-08-24
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多