在TDD开发中，通常要做的第一件事是创建接口，然后开始针对该接口编写单元测试。随着TDD过程的进行，您最终将创建一个实现该接口的类，然后在某个时候您的单元测试将通过。
现在，我的问题是关于私有和受保护的方法，我可能必须在类中编写这些方法以支持接口公开的方法/属性：
类中的私有方法是否应该具有自己的单元测试？
类中的受保护方法是否应具有自己的单元测试？
我的想法：
特别是因为我正在对接口进行编码，所以我不必担心受保护/私有方法，因为它们是黑盒。
因为我使用的是接口，所以我正在编写单元测试以验证所定义的约定是否由实现该接口的不同类正确实现，因此我也不必担心私有/受保护的方法，而应该通过调用接口定义的方法/属性。
如果我的代码覆盖率未显示出受保护的/私有方法被击中，则我没有正确的单元测试，或者我的代码未被使用，应删除。
Answers:
不，我不认为要测试私有或受保护的方法。类的私有方法和受保护方法不是公共接口的一部分，因此它们不公开公共行为。通常，这些方法是通过将测试变为绿色后所应用的重构来创建的。
因此，这些私有方法由声明公共接口行为的测试隐式测试。
从哲学的角度讲，请记住，您是在测试行为，而不是方法。因此，如果您想到被测类可以做的事情，只要您可以测试并断言该类的行为符合预期，则该类内部是否使用私有（和受保护）方法来实现这种行为是无关紧要的。这些方法是公共行为的实施细节。
我不同意大多数海报。
最重要的规则是：工作代码敲打有关公共/保护/私有的理论规则。
您的代码应经过全面测试。如果您可以通过编写针对公共方法的测试来达到目标，那么就可以充分利用受保护/私有方法，那就太好了。
如果不能，则可以重构以便可以，或者修改受保护/专用规则。
关于一位心理学家给孩子们做过测试的故事很有趣。他给每个孩子两个木板，木板的两端都系着绳子，并要求他们越过一个房间，不要脚踩到地板上。所有的孩子都用木板像小雪橇一样，每只脚踩一只脚，用绳子抓住它们，然后在地板上滑动。然后他给了他们同样的任务，但是只用了一块木板。他们在地板上枢转/“行走”，在单板的每一端都用了一只脚-他们更快！
仅仅因为Java（或任何语言）具有（私有/受保护/公共）功能并不意味着您正在使用它来编写更好的代码！
现在，将始终存在优化/最小化此冲突的方法。在大多数语言中，可以将方法设置为受保护的方法（而不是公共方法），并将测试类放入同一程序包（或其他程序包）中，该方法将可用于测试。如其他张贴者所述，有一些注释可以提供帮助。您可以使用反射来获取私有方法（糟糕）。
上下文也很重要。如果您要编写供外部人员使用的API，则公共/私有更为重要。如果是内部项目，谁在乎？
但是，归根结底，请考虑一下由于缺乏测试而导致了多少错误。然后比较“过分可见”的方法引起了多少错误。该答案将推动您做出决定。
你写了：
在TDD开发中，通常要做的第一件事是创建接口，然后开始针对该接口编写单元测试。随着TDD过程的进行，您最终将创建一个实现该接口的类，然后在某个时候您的单元测试将通过。
请让我用BDD语言改写一下：
在描述一个类为何有价值的原因及其行为方式时，通常要做的第一件事是创建一个如何使用该类的示例，通常通过其接口*。添加所需的行为时，最终会创建一个提供该值的类，然后在某些时候您的示例起作用。
*可以是
Interface该类的实际或简单的可访问API，例如：Ruby没有接口。
这就是为什么您不测试私有方法的原因-因为测试是如何使用该类的示例，因此您实际上不能使用它们。如果要执行的操作是将私有方法中的职责委派给协作类，然后对辅助程序进行模拟/存根。
对于受保护的方法，您是说扩展您的类的类应具有某些特定的行为并提供某些值。然后，您可以使用类的扩展来演示该行为。例如，如果您正在编写一个有序的集合类，则可能要证明两个具有相同内容的扩展名具有相等性。
希望这可以帮助！
编写测试有两个原因：
承担（1）声明预期行为：
在断言预期的行为时，您要确保代码按预期的方式工作。这实际上是一种自动化的方式，可以执行例行验证，任何开发人员在实施任何类型的代码时都会执行以下操作：
这些都是我们所有人都会想到的问题，通常，我们也会尝试在脑海中执行代码，确保它看起来确实有效。对于这些情况，让计算机以确定的方式回答这些问题通常很有用。因此，我们编写了一个断言确实有效的单元测试。这使我们对代码充满信心，可以帮助我们及早发现缺陷，甚至可以帮助实际实施代码。
在需要的地方进行此操作是个好主意。任何难以理解的代码，或非琐碎的代码。即使是平凡的代码也可以从中受益。这完全取决于您自己的信心。多久做一次和走多远取决于您自己的满意程度。当您可以自信地回答“是”时，请停下来：您确定这样做有效吗？
对于这种测试，您不需要关心可见性，界面或其他任何方面，而只关心拥有有效的代码。因此，是的，如果您认为需要对它们进行测试以回答问题的“是”，则可以测试私有和受保护的方法。
承担（2）防止行为回归：
一旦获得了有效的代码，就需要有一种机制来保护该代码免受将来的损害。如果没有人再次接触您的源和配置，则不需要此操作，但是在大多数情况下，您或其他人将接触您的源和软件的配置。这种内部麻烦很可能破坏您的工作代码。
大多数语言中已经存在机制来防止这种损坏。可见性功能是一种机制。私有方法被隔离并隐藏。封装是另一种机制，您可以对事物进行分隔，因此更改其他分隔不会影响其他分隔。
通用的机制称为：边界编码。通过在代码各部分之间创建边界，可以保护边界内的所有内容免受其外部内容的影响。边界成为相互作用的点，以及事物相互作用的契约。
这意味着对边界的更改（通过破坏其接口或破坏其预期的行为）将损坏并可能破坏依赖于该边界的其他边界。这就是为什么有一个单元测试的好主意，它针对这些边界并断言它们在语义和行为上都没有改变。
这是您的典型单元测试，是大家在提及TDD或BDD时谈论的话题。重点是加强边界并保护它们不受更改。您不想为此测试私有方法，因为私有方法不是边界。受保护的方法是受限制的边界，我会保护它们。它们没有暴露于世界，但是仍然暴露于其他隔间或“单位”。
该怎么做？
正如我们所看到的，有充分的理由对公共方法和受保护方法进行单元测试，以断言我们的接口没有改变。而且有充分的理由测试私有方法，以断言我们的实现工作。那么我们应该对它们全部进行单元测试吗？
是和否
首先：测试所有您认为需要确定性证明的方法，以便能在大多数情况下确保您的代码有效，无论可见性如何。然后，禁用这些测试。他们已经完成了工作。
最后：为您的边界编写测试。对将由系统其他单元使用的每个点进行单元测试。确保此测试声明语义约定，方法名称，参数数量等。还确保测试声明单元的可用行为。您的测试应演示如何使用该设备以及该设备可以做什么。使这些测试保持启用状态，以便它们在每次代码推送时都运行。
注意：禁用第一组测试的原因是为了允许进行重构工作。主动测试是代码耦合。它可以防止将来修改正在测试的代码。您只需要为您的界面和交互合同使用。
如果您的目标是提高代码覆盖率（我建议您这样做），则应测试所有方法，无论它们是私有的还是受保护的。
受保护是一种不同的讨论点，但总而言之，它根本不应该存在。要么破坏对已部署代码的封装，要么迫使您从该类继承，仅对其进行单元测试，甚至有时您不需要继承。
仅仅向客户隐藏一个方法（私有化）并不能赋予它不被审核的特权。因此，可以通过前面提到的公共方法来测试它们。
我同意其他所有人的观点：您的问题的答案是“否”。
确实，您完全正确地对待了您的方法和想法，尤其是在代码覆盖率方面。
我还要补充一点，这个问题（和答案为“否”）也适用于您可能会引入类的公共方法。
另外，对于C ++（我应该只考虑C ++），我仅使用私有方法来实现接口，以指示仅应通过其实现的接口来使用该类。这避免了我错误地从测试中调用添加到实现中的新方法
好的设计意味着将应用程序分成多个可测试的单元。完成此操作后，某些单元将公开使用公共API，而另一些可能不会。同样，暴露单元与这些“内部”单元之间的交互点也不是公共API的一部分。
我认为，一旦有了可识别的单元，无论是否通过公共API公开，都将受益于单元测试。