为什么将单元测试专用方法视为不良做法？

内容：

我目前正在使用Python进行一个小项目。我通常使用一些公开的方法来构造我的类，这些方法已记录在案，但主要处理高级概念（类的用户应了解和使用的内容），以及一堆隐藏的（从下划线开始）负责方法的类。复杂或低级别的处理。

我知道测试对于确保代码的信心并确保以后进行的任何修改都不会破坏以前的行为至关重要。

问题：

为了在受信任的基础上构建更高级别的公共方法，我通常会测试私有方法。我发现查找代码修改是否已引入回归以及在何处更容易。这意味着这些内部测试可能会因次要修订而中断，并且需要修复/替换

但是我也知道，单元测试私有方法至少是一个有争议的概念，或者更经常被认为是不好的做法。原因是：仅应测试公共行为（参考）

题：

我确实关心以下最佳做法，并希望了解：

• 为什么在私有/隐藏方法上使用单元测试不好（有什么风险）？
• 当公共方法可以使用低级和/或复杂处理时，最佳实践是什么？

精度：

• 这不是一个如何的问题。Python没有真正的隐私概念，隐藏的方法根本没有列出，但是当您知道它们的名称时就可以使用
• 我从没学过编程规则和模式：我的上一堂课是80年代的...我主要通过尝试和失败以及在Internet上的引用来学习语言（多年来，Stack Exchange是我的最爱）

有两个原因：

1. 通常，当您想测试类的私有方法时，这是一种设计气味（iceberg类，可重复使用的公共组件不足等）。几乎总是存在一些“较大”的问题。

2. 您可以通过公共接口测试它们（这就是您要测试它们的方式，因为这是客户端调用/使用它们的方式）。通过查看私有方法的所有通过测试的绿灯，您可能会得到错误的安全感。通过公共接口在私有功能上测试边缘情况会更好/更安全。

3. 通过测试专用方法，您可能会面临严重的测试重复（看起来/感觉非常相似的测试）的风险。当需求改变时，这将产生严重的后果，因为过多的测试将被打破。它还可能使您因测试套件而难以重构……这是最终的讽刺意味，因为测试套件可帮助您安全地进行重新设计和重构！

如果您仍然想测试私有部分（如果它困扰您和YMMV，请不要使用它，但是过去对我有用，请不要使用它）：有时为私有函数编写单元测试只是为了确保他们正在按照您认为自己有价值的方式工作（特别是如果您不熟悉某种语言）。但是，在确定它们可以正常工作之后，请删除测试，并始终确保面向公众的测试是可靠的，并且在有人对上述私有功能进行了重大更改的情况下将其捕获。

何时测试私有方法：由于这个答案已经（某种程度上）流行了，我不得不提一句“最佳实践”总是这样：“最佳实践”。这并不意味着您应该教条主义或盲目地这样做。如果您认为应该测试自己的私有方法并且有正当的理由（例如您正在为旧版应用程序编写特性测试），那么请测试您的私有方法。特定情况总是胜过任何一般规则或最佳做法。请注意一些可能出错的问题（请参见上文）。

我有一个关于SO的详细解答，我在这里不再重复：https : //stackoverflow.com/questions/105007/should-i-test-private-methods-or-only-public-ones/ 47401015＃47401015

鉴于单元测试的主要目的之一是您可以重构程序的内部结构，然后能够验证您是否没有破坏其功能，因此，如果单元测试以如此精细的粒度进行操作会适得其反程序代码的任何更改都要求您重写测试。

为私有方法编写单元测试会将单元测试与实现细节联系起来。

单元测试应该在类的外表面（它是公共API）上测试类的行为。单元测试不必了解有关类的内部知识。当需要重构时，针对类的实现细节编写单元测试会很费力。重构几乎肯定会破坏这些测试，因为它们不是稳定API的一部分。

这就是说，为什么可能要编写单元测试你的私有方法？

在单元测试和增量开发之间存在自然的张力。使用REPL（读-评估-打印循环）的软件开发人员可以证明，当您“增长”一个类或功能时，快速编写和测试少量功能是多么有效。在单元测试驱动的环境中执行此操作的唯一好方法是为私有方法编写单元测试，但是这样做会遇到很多麻烦。单元测试需要花费一些时间来编写，您需要一个实际的方法来进行测试，并且您的测试框架需要支持将方法保持私有状态的能力，以免污染您的外部API。

诸如C＃和.NET的某些生态系统可以创建类似于REPL的环境（如Linqpad之类的工具可以这样做），但是它们的实用程序受到限制，因为您无权访问您的项目。Visual Studio中的即时窗口不方便；它仍然没有完整的Intellisense，您必须在其中使用完全限定的名称，并且每次使用它都会触发构建。

根据我的经验，我发现对内部类，方法进行单元测试通常意味着我必须将经过测试的函数，类删除。创建另一个抽象级别。

这导致更好地遵守单一责任原则。

我认为这是一个好问题，因为它暴露了测试覆盖率中的常见问题。但是一个好的答案应该告诉您这个问题并不完全正确，因为从理论上讲，您不应该对私有方法进行单元测试。这就是为什么它们是私有的。

也许更好的问题是“当我想测试私有方法时该怎么办？” ，答案很明显：您应该以一种使测试成为可能的方式来公开它们。现在，这并不一定意味着您应该只公开该方法而已。您很可能希望进行更高的抽象；移至其他库或API，以便您可以在该库上进行测试，而无需在主API中暴露该功能。

请记住，您的方法具有不同的可访问性级别是有原因的，因此您应该始终考虑最终将如何使用您的类。