由于某些原因，我不喜欢测试私有功能。它们如下（这些是TLDR人员的要点）：
- 通常，当您想测试类的私有方法时，这是一种设计气味。
- 您可以通过公共接口测试它们（这就是您要测试它们的方式，因为这是客户端调用/使用它们的方式）。通过查看私有方法所有通过测试的绿灯，您可能会得到错误的安全感。通过公共接口在私有功能上测试边缘情况会更好/更安全。
- 通过测试专用方法，您可能会面临严重的测试重复（看起来/感觉非常相似的测试）的风险。当需求改变时，这将产生严重的后果，因为过多的测试将被打破。它还可能使您因测试套件而难以重构……这是最终的讽刺意味，因为测试套件可帮助您安全地进行重新设计和重构！
我将用一个具体的例子来解释每一个。事实证明2）和3）有点错综复杂，所以它们的示例相似，尽管我认为它们是您不应该测试私有方法的单独原因。
有时候测试私有方法是合适的，了解上面列出的缺点很重要。我将在后面详细介绍。
我还将讨论为什么TDD最终并不是测试私有方法的有效借口。
重构出不良设计的出路
我看到的最常见的（反）模式之一是Michael Feathers所说的“ Iceberg”课（如果您不知道Michael Feathers是谁，那就去买/读他的书“使用Legacy Code有效地工作”。一个值得了解您是否是专业软件工程师/开发人员的人）。还有其他（反）模式会使此问题浮出水面，但这是我偶然发现的最常见的模式。“ Iceberg”类有一个公共方法，其余的是私有方法（这就是为什么要尝试测试私有方法的原因）。之所以称为“ Iceberg”类，是因为通常会出现一个单独的公共方法，但是其余功能以私有方法的形式隐藏在水下。
例如，您可能希望GetNextToken()通过在字符串上依次调用它并返回预期结果来进行测试。像这样的函数确实需要进行测试：这种行为并非微不足道，尤其是在分词规则复杂的情况下。让我们假装它并不是那么复杂，我们只想捆绑以空格分隔的令牌。因此，您编写了一个测试，也许看起来像这样（某些语言不可知的伪代码，希望这个想法很清楚）：
TEST_THAT(RuleEvaluator, canParseSpaceDelimtedTokens)
{
input_string = "1 2 test bar"
re = RuleEvaluator(input_string);
ASSERT re.GetNextToken() IS "1";
ASSERT re.GetNextToken() IS "2";
ASSERT re.GetNextToken() IS "test";
ASSERT re.GetNextToken() IS "bar";
ASSERT re.HasMoreTokens() IS FALSE;
}
好吧，实际上看起来还不错。我们希望确保在进行更改时保持这种行为。但是GetNextToken()是私有功能！因此，我们无法像这样测试它，因为它甚至不会编译（假设我们使用的是某种实际上强制执行public / private的语言，这与某些脚本语言（如Python）不同）。但是，如何改变RuleEvaluator班级以遵循单一责任原则（Single Responsibility Principle）呢？例如，我们似乎有一个解析器，标记器和评估器被卡在一个类中。仅将这些职责分开会更好吗？最重要的是，如果您创建一个Tokenizer类，则它的公共方法将是HasMoreTokens()and GetNextTokens()。本RuleEvaluator类可以有Tokenizer对象为成员。现在，我们可以保持与上面相同的测试，除了我们要测试的是Tokenizer类而不是RuleEvaluator类。
这是UML中的样子：
请注意，这种新设计提高了模块化，因此您有可能在系统的其他部分重用这些类（在定义之前，私有方法不可重用）。这是将RuleEvaluator分解的主要优点，并且具有更高的可理解性/局部性。
该测试看起来非常相似，不同之处GetNextToken()在于，由于该方法现已在Tokenizer该类上公开，因此这次实际上将进行编译：
TEST_THAT(Tokenizer, canParseSpaceDelimtedTokens)
{
input_string = "1 2 test bar"
tokenizer = Tokenizer(input_string);
ASSERT tokenizer.GetNextToken() IS "1";
ASSERT tokenizer.GetNextToken() IS "2";
ASSERT tokenizer.GetNextToken() IS "test";
ASSERT tokenizer.GetNextToken() IS "bar";
ASSERT tokenizer.HasMoreTokens() IS FALSE;
}
通过公共接口测试私有组件，并避免测试重复
即使您不认为可以将问题分解为更少的模块化组件（如果您尝试这样做，也可以在95％的时间中做到），也可以通过公共接口简单地测试私有功能。很多时候，私人成员不值得测试，因为他们将通过公共界面进行测试。我经常看到的测试看起来非常相似，但是测试了两种不同的功能/方法。最终发生的事情是，当需求发生变化（并且总是如此）时，您现在有2个不合格的测试，而不是1个。如果您真的测试了所有私有方法，则可能有10个不合格的测试而不是1个。 ，测试私有功能（通过使用FRIEND_TEST或将其公开或使用反射），否则可以通过公共界面进行测试，这可能会导致测试重复。您确实不希望这样做，因为没有什么比测试套件使您放慢脚步伤害更大。应该减少开发时间并降低维护成本！如果您测试通过公共接口以其他方式测试的私有方法，则测试套件可能会做相反的事情，从而积极增加维护成本并增加开发时间。当您公开私有函数时，或者如果您使用类似FRIEND_TEST和/或反射的方法，从长远来看，您通常会后悔。
考虑Tokenizer该类的以下可能实现：
假设这SplitUpByDelimiter()负责返回一个数组，使得数组中的每个元素都是一个标记。此外，我们只说这GetNextToken()只是此向量的迭代器。因此，您的公开测试可能看起来像这样：
TEST_THAT(Tokenizer, canParseSpaceDelimtedTokens)
{
input_string = "1 2 test bar"
tokenizer = Tokenizer(input_string);
ASSERT tokenizer.GetNextToken() IS "1";
ASSERT tokenizer.GetNextToken() IS "2";
ASSERT tokenizer.GetNextToken() IS "test";
ASSERT tokenizer.GetNextToken() IS "bar";
ASSERT tokenizer.HasMoreTokens() IS false;
}
假装我们拥有迈克尔·费瑟（Michael Feather）所说的摸索工具。此工具可让您触摸其他人的私处。一个示例FRIEND_TEST来自googletest，如果语言支持，则进行反射。
TEST_THAT(TokenizerTest, canGenerateSpaceDelimtedTokens)
{
input_string = "1 2 test bar"
tokenizer = Tokenizer(input_string);
result_array = tokenizer.SplitUpByDelimiter(" ");
ASSERT result.size() IS 4;
ASSERT result[0] IS "1";
ASSERT result[1] IS "2";
ASSERT result[2] IS "test";
ASSERT result[3] IS "bar";
}
好吧，现在让我们说需求发生了变化，令牌化变得更加复杂。您确定一个简单的字符串定界符将无法满足需要，并且需要一个Delimiter类来处理作业。自然，您会期望一项测试能够通过，但是当您测试私有功能时，这种痛苦会增加。
什么时候可以测试私有方法？
软件中没有“一刀切”的功能。有时“违反规则”是可以的（并且实际上是理想的）。我强烈建议不要在可能的情况下测试私有功能。我认为可以的主要情况有两种：
我已经与遗留系统进行了广泛的合作（这就是为什么我是Michael Feathers的忠实拥护者），并且我可以肯定地说，有时仅测试私有功能最安全。这对于将“特性测试”纳入基线特别有用。
您很着急，现在和现在都必须做最快的事情。从长远来看，您不想测试私有方法。但是我会说，重构通常需要一些时间来解决设计问题。有时您必须在一周内发货。没关系：如果您认为这是完成工作的最快，最可靠的方法，则可以快速而又肮脏地使用摸索工具测试私有方法。但是要了解，从长远来看，您所做的工作不是最佳的，请考虑重新使用它（或者，如果忘记了它，但是稍后看到它，请修复它）。
可能还有其他情况也可以。如果您认为还可以，并且您有充分的理由，那么请这样做。没有人阻止你。请注意潜在的成本。
TDD借口
顺便说一句，我真的不喜欢使用TDD作为测试私有方法的借口。我练习TDD，但我认为TDD不会强迫您这样做。您可以先编写测试（针对公共接口），然后编写满足该接口的代码。有时我会为公共接口编写测试，而我也会通过编写一个或两个较小的私有方法来满足它（但我不会直接测试私有方法，但我知道它们可以工作，否则我的公共测试会失败）。如果我需要测试该私有方法的边缘情况，我将编写一堆测试，这些测试将通过我的公共接口进行测试。如果您不知道如何处理极端情况，则这是一个强烈的信号，您需要将其重构为每个都有自己的公共方法的小组件。这表明您私有函数做得太多，超出了类的范围。
另外，有时我发现我编写的测试现在无法满足需要，因此我认为“嗯，等我有更多的API可以使用时，我会稍后再返回该测试。” '将其注释掉并保留在我的脑海中）。在这里，我遇到的许多开发人员将开始使用TDD作为替罪羊为其私有功能编写测试。他们说：“哦，我还需要其他测试，但是要编写该测试，我需要这些私有方法。因此，由于如果不编写测试就无法编写任何生产代码，因此我需要编写测试用于私有方法。” 但是他们真正需要做的是将其重构为更小且可重用的组件，而不是在当前类中添加/测试一堆私有方法。
注意：
不久前，我回答了一个有关使用GoogleTest测试私有方法的类似问题。我在这里大部分修改了该答案，使其与语言无关。
PS这是迈克尔·费瑟斯（Michael Feathers）关于冰山课程和摸索工具的相关演讲：https : //www.youtube.com/watch?v=4cVZvoFGJTU