主持人注:这里已经有39个答案了(有些已经删除了)。在你发表你的答案之前,考虑一下你是否可以为讨论添加一些有意义的东西。你很可能只是在重复别人已经说过的话。


我偶尔发现自己需要将类中的私有方法设为public,只是为了为它编写一些单元测试。

通常这是因为该方法包含类中其他方法之间共享的逻辑,并且单独测试逻辑更整洁,或者另一个原因可能是我想测试同步线程中使用的逻辑,而不必担心线程问题。

其他人发现他们这样做是因为我不喜欢吗?我个人认为,公开一个方法的好处超过了它在类之外没有提供任何服务的问题……

更新

谢谢大家的回答,似乎引起了大家的兴趣。我认为普遍的共识是测试应该通过公共API进行,因为这是使用类的唯一方式,我非常同意这一点。在我上面提到的几个案例中,我会这样做,这是不常见的情况,我认为这样做的好处是值得的。

然而,我可以看到,每个人都指出它不应该真的发生。再仔细想想,我觉得改变你的代码来适应测试是一个坏主意——毕竟我认为测试在某种程度上是一个支持工具,而改变一个系统来“支持一个支持工具”是明显的坏做法。


当前回答

You should never ever ever let your tests dictate your code. I'm not speaking about TDD or other DDs I mean, exactly what your asking. Does your app need those methods to be public. If it does then test them. If it does not then then don't make them public just for testing. Same with variables and others. Let your application's needs dictate the code, and let your tests test that the need is met. (Again I don't mean testing first or not I mean changing a classes structure to meet a testing goal).

相反,你应该“考高一点”。测试调用私有方法的方法。但是您的测试应该测试您的应用程序需求,而不是您的“实现决策”。

例如(此处为bod伪代码);

   public int books(int a) {
     return add(a, 2);
   }
   private int add(int a, int b) {
     return a+b;
   } 

没有理由测试“add”,你可以测试“books”。

永远不要让你的测试为你做代码设计决策。测试你是否得到了预期的结果,而不是你如何得到结果。

其他回答

我通常将这些方法保留为受保护的,并将单元测试放在相同的包中(但在另一个项目或源文件夹中),在那里它们可以访问所有受保护的方法,因为类装入器将把它们放在相同的名称空间中。

在我看来,在编写测试时,你不应该对你的类内部是如何实现的做深入的假设。您可能希望稍后使用另一个内部模型对其进行重构,但仍然保证与以前的实现相同。

记住这一点,我建议你把重点放在测试你的契约仍然存在,不管你的类目前有什么内部实现。基于属性的公共api测试。

当您想要测试的某个方法中有复杂的逻辑时,这是一个很好的指标,表明该类违反了单一责任原则。

一个很好的解决方案是:

为原始方法的功能创建一个接口。 在类中实现并测试该接口。 将接口注入到原始类中。

更新:我已经在其他很多地方对这个问题增加了一个更广泛、更完整的答案。这可以在我的博客上找到。

如果我需要公开一些东西来测试它,这通常暗示被测试的系统没有遵循单一责任原则。因此,应该引入一个缺失的类。将代码提取到一个新类后,将其设为public。现在您可以轻松地进行测试,并且遵循SRP。您的其他类只需通过组合调用这个新类。

使方法公开/使用语言技巧,例如将代码标记为对测试程序集可见,应该始终是最后的手段。

例如:

public class SystemUnderTest
{
   public void DoStuff()
   {
      // Blah
      // Call Validate()
   }

   private void Validate()
   {
      // Several lines of complex code...
   }
}

通过引入验证器对象重构此对象。

public class SystemUnderTest
{
    public void DoStuff()
    {
       // Blah
       validator.Invoke(..)
    }
}

现在我们要做的就是测试验证器是否被正确调用。验证的实际过程(以前的私有逻辑)可以在完全隔离的情况下进行测试。不需要复杂的测试设置来确保验证通过。

一些很棒的答案。我没有看到提到的一件事是,在测试驱动开发(TDD)中,私有方法是在重构阶段创建的(关于重构模式的示例,请参阅Extract Method),因此应该已经具有必要的测试覆盖率。如果做得正确(当然,当涉及到正确性时,您将得到各种各样的意见),您应该不必担心必须将私有方法设为公共,以便您可以测试它。