我知道（并同意）将单元测试放在单独的程序集中的常见论点。但是，最近我遇到了一些我真的想测试私有方法的情况。所讨论的幕后逻辑非常复杂，以至于测试公共和内部接口并不能完全完成工作。对类的公共接口的测试感觉过度劳累，我看到一些针对私有的测试可以更简单有效地完成工作的地方。
protected在过去，我通过制作我需要测试的东西，并创建一个我可以在测试框架中使用它的子类来解决这些情况。但这在应该是sealed. 更不用说用所有的脚手架使测试框架膨胀了。
所以我正在考虑这样做：在课堂上放置一些测试，在那里他们可以得到私人成员。但是使用“#if DEBUG”将它们排除在生产代码之外。
这看起来是个好主意吗？
OP 问题的解决方案是将 IoC 与 DI 正确结合，并完全消除测试私有方法的需要（正如Joel Martinez 指出的那样）。正如多次 提到的，单元测试私有成员不是要走的路。
但是，有时您不能更改代码（遗留系统、破坏更改的风险 - 您可以命名），也不能使用允许私人成员测试的工具（例如 Typemock，它是付费产品）。对于这种情况，您要么根本不测试，要么偷工减料。我相信这是OP面临的情况。
请记住，您可以使用反射来访问和调用私有成员。
在我看来，在类本身中放置条件调试是一个相当糟糕的主意——它给类代码增加了噪音（比如，一些不相关的东西）。当然，它会在发布时消失，但您（可能还有其他程序员）将不得不在日常基础上处理它。
我意识到您的想法在纸上听起来可能不错 - 包含条件调试的简单测试。但实际上，测试很快就会使用额外的变量（这些也必须放在类代码中）、一些实用程序（额外的引用、自定义类型）、测试框架（甚至更多的引用）等等。这一切都必须以某种方式连接到类代码。把所有这些放在一起，你很快就会变成一个无法维护的怪物。
你确定要处理它吗？特别是考虑到将简单的基于反射的实用程序放在一起可能并不难。
如果您需要独立于类的公共 API 测试此方法，那么听起来像是从类本身中删除的候选者。
您可以说该类依赖于私有方法（可以说需要将其与类公共 API 分开测试，这很明显）。
如果仅通过测试该类型的公共 API 无法满足此依赖关系，则让该类将此依赖关系委托给另一种类型。您可以在内部实例化此类型，也可以注入/解析此类型。
这种新类型可以有自己的单元测试，因为它的公共 API 将表达以前的私有方法。