我想测试一个私有方法 - 我的设计有问题吗？ [英] I want to test a private method - is there something wrong with my design?

问题描述

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

So I'm extremely new to software testing, and am looking at adding a couple of tests to one of my applications. I have a public method addKeywords() which along the way calls a private method removeInvalidOperations(). This private method makes calls to an external API and is ~50 lines of code. As I consider this to be a somewhat complex method I would like to test this without having to do so through calling the addKeyword() method. Yet this does not seem to be possible (at least not though JUnit).

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

The information I have looked at is suggesting that the desire to test ones private methods could be a code smell. Some people suggest that it may be a sign that this should be refactored into a separate class and made public. Also, there are the suggestions that if you really need to then you can make edits to your production code e.g. change the visibility of the private method.

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

I don't really see why I have a problem with my current code design, but also don't like the idea of editing my production code to suit my tests needs.

正如我所说 - 我对测试很新，所以任何帮助都非常感谢。另外，如果有任何进一步的信息可以帮助我解答，请告诉我。

As I say - I'm rather new to testing, so any help is much appreciated. Also, please let me know if there is any further info I can provide to help with the answers.

推荐答案

我建议重构一下。

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

The information I have looked at is suggesting that the desire to test ones private methods could be a code smell. Some people suggest that it may be a sign that this should be refactored into a separate class and made public.

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

You have covered the various reasons for and against it in your own question, you seem to be well aware of the arguments. But you have a method that seems rather complicated and involves an external API. That is worth testing on its own. removeInvalidOperations() can still be a private method on the class it is in, but it would basically delegate to another dependency.

class YourClass
{
    private OperationRemover remover;

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

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

这为您提供了更换的额外好处这种依赖性在某些时候，包括能够测试你的 addKeywords（）方法而不实际放置外部API调用，这将使测试该方法更容易。例如， OperationRemover 可以是一个接口，出于测试目的，您只需传入一个存根而不是生产中使用的具体版本。至于你的具体版本，你可以独立于你现有的课程，为它编写测试。

This gives you the added benefit of being able to replace this dependency at some point, including being able to test your addKeywords() method without actually placing an external API call, which would make testing that method easier. OperationRemover could be an interface, for example, and for testing purposes, you simply pass in a stub in its place instead of the concrete version used in production. As for your concrete version, you can write tests for it independently of what is happening with your existing class.

我真的没看到为什么我的当前代码设计有问题，
但也不喜欢编辑我的生产代码以满足我的
测试需求的想法。

I don't really see why I have a problem with my current code design, but also don't like the idea of editing my production code to suit my tests needs.

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

Easier testability is a side-benefit. Look at it another way: What you are actually doing is making the code loosely-coupled and extensible. Above, we have separated the call to the external API from the code that might need to use the result. The external API could change. You might go from one service to another, but the code that uses the result does not have to care. That class can stay the same, only the class that actually places the calls needs to be modfied (or replaced).

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

Real world example: The year is 2007 and you work for a bank in a large financial center in the United States. Your application needs to use account information. Your code reaches out to a web service of some sort inside the bank and gets the information it needs, in the shape it needs, then goes on about its processing. In 2008, the US financial sector implodes, and your bank (which is on the verge of collapse) is gobbled up by another bank. Your application is spared, except now you have to reach out to a different API that already exists within the surviving bank to get account information from there. Should the code that consumes this account information need to change? Not necessarily. It's the same account information as before, just from a different source. No, all that needs to change is the implementation invoking the APIs. Consuming code never has to know.

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

The fact that such loose coupling also promotes and facilitates testing is a bonus.

这篇关于我想测试一个私有方法 - 我的设计有问题吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！