java - 如何对有两个公共(public)方法，一个调用另一个的情况进行单元测试？

Question

当有两个公共(public)方法并且一个方法调用同一个类中的另一个公共(public)方法时，如何测试方法？

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

---

一个例子

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

在测试 likedDeck() 时我应该考虑 getWhereFrom() 还是应该假设任何默认情况？如果我考虑默认情况，我会失去输出不是默认的情况。我不确定我应该模拟它，因为正在测试正在调用的类。 Spying/Mocking class under test

Answer 1

你不在乎。

您使用单元测试来单独测试每个公共(public)方法的契约。因此，您编写测试来确保 add() 和 multiply() 执行它们应该执行的操作。

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

仅供记录:您的代码现在已编写；你绝对不要在这里 mock 。这里不需要模拟；并且只会增加测试与实际生产代码无关的内容的风险。 仅在必须控制对象的各个方面以启用测试的情况下使用模拟。但是示例代码中没有任何内容需要进行模拟测试。如果是的话 - 这将表明设计/实现不佳(考虑到这些方法的契约(Contract))!

编辑；给出问题中的更改示例:

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

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

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

换句话说:您所显示的代码可以被修改/重构；例如，为了更清楚地遵循 SRP 。但这当然是一项更大的任务；您需要与周围的人讨论。