在阅读了这个网站上关于这个主题的几个主题之后，我得出了以下结论：
要测试私有方法，有两种选择：
使用 PrivateObject，但 VStudio 2012 的测试工具在进行大量测试时很糟糕，建议使用 NUnit。但是 PrivateObject 使用的命名空间与 NUnit for Asserts 的命名空间发生冲突，因此应避免使用。
将所有私有成员转换为受保护成员（属性+方法），使一个包装类继承被测类，并通过公有方法调用受保护方法。
第二种选择有效，但在我看来，出于测试驱动的原因打破 OO 封装非常尴尬。
我不是要讨论是否应该测试私有方法（在其他线程中已经讨论过这一点），或者使用其他工具，或者为 VStudio 辩护（同上）。
我宁愿听听您关于牺牲 OO 原则而不是可测试性的评论。
谢谢你。
我不明白为什么要测试私有方法。以我最诚实的观点，您不应该仅仅为了测试私有方法而破坏您的 OO 原则。为什么？因为您可能会破坏某些功能/架构或更糟，通过增加您应该是私有方法的可见性来危害安全性。
只有公开的 API（公共）应该进行单元测试。因为这些方法是唯一可以在任何地方看到并且可以访问的方法。这些公共方法使用任何私有的东西。这些方法代表您的业务流程、API。所以只测试公共方法是有意义的，因为这些方法可以被外部访问。
同样，在测试您的公共方法/公开的 API 时，最有可能被您的公共方法使用的私有方法应该已经在您的单元测试范围内。
我至少是从面向对象范式的角度说的。当然，会有人认为单元测试更适合过程/模块化范式，因为单元测试，就其纯粹的定义而言，是测试系统的每一个单元。
每当我测试私有方法时，我刚刚在测试项目中编写了一个基于反射的扩展方法，并使用它来公开函数，因为该方法实际上只是起点，它在那里发生的事情是你对测试感兴趣的，所以在这种情况下，如何并不像为什么那么重要。很多时候人们说，如果某些东西是私有的，那就有问题了，它应该在自己的类中，因为它有自己的责任等等，但是你可以担心以后为什么......
无论如何，对于工具，我建议远离 MSTest 或 Microsoft 集成测试框架，并选择像 Nunit 等开源工具。
这主要是因为在很多情况下，您希望自动化构建并在构建服务器上运行它们，例如 teamcity 或 jenkins（或者在一些罕见和疯狂的情况下 TFS）。但是，如果您要尝试在构建服务器上运行基于 MSTest 的测试，它不会让您不安装 Visual Studio，因为这是测试所需的 dll 所在的位置。所以我认为你的构建服务器不应该为了运行一些测试而安装你的IDE，所以在这种情况下，使用独立且简单的东西是有意义的，比如Nunit，因为你只需要dll和运行器，任务完成。
== 编辑 ==
如果您确实决定通过反射（扩展或硬编码）获取您的私有方法，这里有一个链接应该显示我的意思：
我不会费心更改您的代码，因为您将其私有化是有原因的（无论是对还是错），所以您不妨只花 5 分钟时间来制作一个扩展方法并进行测试，然后如果您意识到它是私有的是一个问题，您只需在测试中删除分机呼叫。
想想你想测试什么逻辑。如果该逻辑在私有方法中，请考虑将其公开。您的测试运行程序就像您的应用程序的用户，所以为什么不授予它访问代码的权限。如果您只需要在另一个公共方法中使用该私有方法的结果，那么只测试公共方法就足够了。
这显然是一个见仁见智的问题。但是要扮演魔鬼的拥护者..以捍卫上述方法2。
测试私有方法通常比测试公共 API 更简单，因此会引导您进行更小、更严格的测试，您可以更有信心地进行测试。
我建议至少继续测试私有方法。通过将您的测试与内部实现耦合，它们变得非常脆弱，并且每当您决定重构代码时，您的许多测试都可能会中断。
这通常要么导致不再重构，因为它破坏了太多测试，要么不再编写单元测试，因为它阻止你重构。
通过类的公共 API 测试行为。不是实现细节。