CC -Dprivate=public

“CC”是我使用的系统上的命令行编译器。-Dfoo=bar相当于#define foo bar。因此，这个编译选项有效地将所有私有内容更改为公共。

我倾向于不使用编译器指令，因为它们很快就会把事情弄得乱七八糟。如果你真的需要它们，一种缓解它的方法是把它们放在一个partial类中，并让你的构建在制作产品版本时忽略那个.cs文件。

我认为应该问的一个更基本的问题是，为什么要首先测试私有方法。这是一种代码气味，你试图通过类的公共接口测试私有方法，而该方法是私有的，因为它是一个实现细节。人们应该只关心公共接口的行为，而不是它在背后是如何实现的。

如果我想测试私有方法的行为，通过使用公共重构，我可以将其代码提取到另一个类中(可能具有包级可见性，以确保它不是公共API的一部分)。然后我可以单独测试它的行为。

重构的产物意味着私有方法现在是一个独立的类，它已经成为原始类的合作者。通过它自己的单元测试，它的行为将被很好地理解。

然后，当我试图测试原始类时，我可以模拟它的行为，这样我就可以集中精力测试该类公共接口的行为，而不必测试公共接口的组合爆炸及其所有私有方法的行为。

我认为这类似于开车。当我开车时，我不会把引擎盖打开，这样我就能看到发动机在工作。我依靠汽车提供的接口，即转速计数器和速度计来知道发动机是否在工作。我依靠的是当我踩下油门踏板时，汽车实际上在移动。如果我想测试引擎，我可以单独检查它。: D

当然，如果您有遗留应用程序，直接测试私有方法可能是最后的手段，但我更希望对遗留代码进行重构，以实现更好的测试。迈克尔·费瑟就这个主题写了一本很棒的书。http://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052

首先，您不应该测试代码的私有方法。你应该测试“公共接口”或API，即类的公共内容。API是所有公开给外部调用者的公共方法。

原因是一旦您开始测试类的私有方法和内部结构，您就将类的实现(私有的东西)耦合到您的测试中。这意味着当您决定更改实现细节时，您也必须更改您的测试。

出于这个原因，你应该避免使用internalsvisibletoattribute。

以下是Ian Cooper关于这个主题的演讲:Ian Cooper: TDD，哪里出了问题

我还使用了InternalsVisibleToAttribute方法。值得一提的是，如果你为了达到这个目的而将你之前的私有方法变成内部方法，那么也许它们不应该成为直接单元测试的对象。

毕竟，您是在测试类的行为，而不是它的具体实现——您可以在不更改前者的情况下更改后者，并且您的测试仍然应该通过。

有时，测试私有声明是很好的。 基本上，编译器只有一个公共方法:Compile(string outputFileName, params string[] sourceSFileNames)。我相信您可以理解，如果不测试每个“隐藏”声明，就很难测试这样的方法!

这就是为什么我们创建了Visual t#:来简化测试。它是一个免费的。net编程语言(兼容c# v2.0)。

我们增加了‘。——“操作符。它就像'。操作符，除了您还可以从测试中访问任何隐藏的声明，而无需更改已测试项目中的任何内容。

看看我们的网站:免费下载。