我知道(并同意)将单元测试放在单独的程序集中的常见论点。但是，最近我遇到了一些我真的很想测试私有(private)方法的情况。所讨论的幕后逻辑非常复杂，以至于测试公共(public)和内部接口(interface)并不能完全完成工作。针对类的公共(public)接口(interface)的测试让人感觉过于紧张，而且我看到了几个地方，在这些地方对私有(private)接口(interface)进行一些测试可以更简单有效地完成工作。
在过去，我通过将我需要测试的东西设为 protected 并创建一个我可以用来在测试框架中获取它的子类来解决这些情况。但这对应该密封 的类来说效果不是很好。更不用说用所有这些脚手架使测试框架膨胀。
所以我正在考虑这样做:在类中放置一些测试，它们可以访问私有(private)成员。但是使用“#if DEBUG”将它们排除在生产代码之外。
这看起来是个好主意吗？
最佳答案
在任何人问之前...
解决方案 OP 的问题是将 IoC 与 DI 正确结合，并完全消除测试私有(private)方法的需要(如 Joel Martinez noted )。如前所述multiple times ，对私有(private)成员进行单元测试不是可行的方法。
但是，有时您不能更改代码(遗留系统，破坏性更改的风险 - 随您便)，也不能使用允许私有(private)成员的工具测试(如 Typemock，它是付费产品)。对于这种情况，您可以根本不测试，或者偷工减料。我认为这是 OP 面临的情况。
将私有(private)方法测试讨论放在一边...
请记住，您可以使用反射 来访问和调用私有(private)成员。
在我看来，将条件调试放在类本身是一个相当糟糕的主意——它给类代码添加了噪音(例如，不相关的东西)。当然，它会在发布时消失，但您(可能还有其他程序员)将不得不在日常基础上处理它。
我意识到您的想法在纸面上听起来不错 - 包含条件调试的简单测试。但实际上，测试很快就会使用额外变量(这些也必须放在类代码中)、一些实用程序(额外引用、自定义类型)， 测试框架(甚至更多引用资料)等等。这一切都必须以某种方式连接到类代码。将所有这些放在一起，您很快就会得到一个无法维护的怪物。
您确定要处理吗？特别是考虑到将简单的基于反射的实用程序放在一起可能并不难。
关于c# - 同一类的单元测试(有条件编译)？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11036389/