我想测试一个私有方法 - 我的设计有问题吗？

Question

所以我对软件测试非常陌生,我正在考虑为我的一个应用程序添加几个测试.我有一个公共方法addKeywords(),它沿途调用私有方法removeInvalidOperations().这种私有方法调用外部API,并且有大约50行代码.我认为这是一个有点复杂的方法,我想通过调用addKeyword()方法来测试它,而不必这样做.然而,这似乎不可能(至少不是JUnit).

我所看到的信息表明,测试私有方法的愿望可能是代码味道.有些人认为这可能表明这应该被重构为一个单独的类并公之于众.此外,还有一些建议,如果您确实需要,那么您可以对生产代码进行编辑,例如更改私有方法的可见性.

我真的不明白为什么我当前的代码设计有问题,但也不喜欢编辑我的生产代码以满足我的测试需求的想法.

正如我所说 - 我对测试很新,所以任何帮助都非常感激.此外,如果有任何进一步的信息,我可以告诉我,以帮助解答.

Answer 1

我建议重构一下.

我所看到的信息表明,测试私有方法的愿望可能是代码味道.有些人认为这可能表明这应该被重构为一个单独的类并公之于众.

你已经在自己的问题中涵盖了支持和反对它的各种原因,你似乎很清楚这些论点.但是你有一个看似相当复杂的方法,并涉及一个外部API.这值得自己测试. removeInvalidOperations()仍然可以是它所在类的私有方法,但它基本上会委托给另一个依赖项.

class YourClass
{
    private OperationRemover remover;

    public void addKeywords() {
        // whatever
        removeInvalidOperations();
    }

    private void removeInvalidOperations() {
         remover.remove();
    }
}

这为您提供了在某些时候能够替换此依赖项的额外好处,包括能够在addKeywords()不实际放置外部API调用的情况下测试您的方法,这将使测试该方法更容易.OperationRemover例如,可以是一个接口,并且出于测试目的,您只需传入一个存根而不是生产中使用的具体版本.至于具体版本,您可以独立于现有类的内容编写测试.

我真的不明白为什么我当前的代码设计有问题,但也不喜欢编辑我的生产代码以满足我的测试需求的想法.

更易于测试是一项附带好处.再看看它:你实际做的是使代码松散耦合和可扩展.上面,我们将调用外部API与可能需要使用结果的代码分开.外部API可能会发生变化.您可能从一个服务转到另一个服务,但使用该结果的代码不必关心.该类可以保持不变,只有实际调用的类需要修改(或替换).

现实世界的例子:这一年是2007年,你在美国一家大型金融中心的银行工作.您的应用程序需要使用帐户信息.您的代码可以访问银行内部的某种Web服务,并以所需的形式获取所需的信息,然后继续处理它.2008年,美国金融业崩溃,你的银行(即将崩溃的边缘)被另一家银行吞并.您的应用程序可以免除,除非您现在必须使用已存在的银行中已存在的其他API来从中获取帐户信息.消费此帐户信息的代码是否需要更改？不必要.它与以前的帐户信息相同,只是来自不同的来源.不,所有需要改变的是调用API的实现.消费代码永远不必知道.

这种松散耦合也促进和促进测试的事实是一个奖励.

Answer 2

如果是的话private,它不能被视为应用程序API的一部分,所以测试它确实是代码味道 - 当测试中断时,是否可以？

单元测试应该是面向功能的,而不是面向代码的.您测试功能单元,而不是代码单元.

无论理论如何,实现之外的类都不能在不破坏JVM的情况下访问私有方法,所以你运气不好 - 你要么必须改变方法的可见性,要么让protected单元测试类扩展测试API,要么测试通过调用使用它的公共方法间接地实现该功能.