在VS2012中对dotnet进行单元测试的最佳选择？

Question

在阅读本网站主题的几个主题后，我得出以下结论：

要测试私人方法，有两个选择：

• 使用PrivateObject，但是在进行大量测试时，VStudio 2012的测试工具很糟糕，建议使用NUnit但是PrivateObject使用的命名空间与NUnit for Asserts的命名空间相撞，所以，应该避免。

• 转换受保护成员（属性+方法）中的所有私有成员，并使包装类继承测试类并通过公共方法调用受保护方法。

第二种选择可行但是在我看来，由于测试驱动的原因而打破OO封装非常尴尬。

我不是要讨论是否应该测试私有方法（在其他线程中已经讨论过），或者使用其他工具，或者保护VStudio（idem）。

我宁愿听到你对牺牲OO原则而不是可测试性的评论。

谢谢。

Answer 1

我无法理解为什么要测试私有方法。在我最诚实的意见中，你不应该仅仅为了测试私有方法而违反你的OO原则。为什么？因为您可能会破坏某些功能/架构或更糟糕，通过增加应该是私有方法的可见性来危害安全性。

只有暴露的API（公共）应进行单元测试。因为这些方法是唯一可以在任何地方访问的方法。这些公共方法使用私有的东西。这些方法代表您的业务流程API。因此，仅测试公共方法是有意义的，因为这些方法将是外部可以访问的方法。

同样，在测试公共方法/公开API时，公共方法最有可能使用的私有方法应该已经在单元测试范围内。

我至少在OO范式的角度讲。当然，有一些论点认为单元测试更适合于程序/模块化范例，因为单元测试的纯粹定义是测试系统的每一个单元。

Answer 2

每当我测试私有方法时，我刚刚在测试项目中编写了一个基于反射的扩展方法，并且只是用它来公开函数，因为实际上该方法只是起点，它在那里发生了你感兴趣的内容在测试中，所以 在这种情况下不如为什么那么重要。很多时候人们会说如果某些东西是私密的，那就有问题，它应该在自己的班级中，因为它有自己的责任等，但是你可以担心之后的原因...

无论如何，对于工具，我建议远离MSTest或Microsoft集成测试框架，并选择像Nunit等开源软件。

这主要是因为在很多情况下，您希望自动化构建并在构建服务器上运行它们，例如teamcity或jenkins（或者在一些罕见且疯狂的情况下TFS）。但是，如果您尝试在构建服务器上运行基于MSTest的测试，则不会安装Visual Studio，因为这是测试所需的dll所在的位置。所以我不认为你的构建服务器应该只安装你的IDE来运行一些测试，所以在这种情况下使用自包含和简单的东西是有意义的，比如Nunit那样你只需要dll和runner，完成工作。

==编辑==

如果您决定通过反射（扩展或硬编码）获取私有方法，这里有一个链接应该显示我的意思：

How do I use reflection to invoke a private method?

我不打扰更改你的代码，因为你有私有理由（无论是对还是错），所以你也可以花5分钟做一个扩展方法并做你的测试，然后如果你意识到让它私有是一个问题，你只需在测试中删除扩展调用。

Answer 3

考虑您要测试的逻辑。如果该逻辑位于私有方法内，请考虑将其公开。您的测试运行器就像您的应用程序的用户，所以为什么不让它访问代码。如果您只需要在另一个公共方法中使用该私有方法的结果，那么仅测试公共方法就足够了。

Answer 4

这显然是一个意见问题。然而，扮演魔鬼的拥护者......为上面的方法2辩护。

通常，测试私有方法比测试公共API更简单，因此可以引导您进行更小，更严格的测试，您可以更好地信任。

Answer 5

我建议至少继续测试私有方法。通过将测试与内部实现相结合，它们变得非常脆弱，并且每当您决定重构代码时，许多测试都可能会中断。

这通常会导致不再重构，因为它会破坏太多的测试，或者不再编写单元测试，因为它会阻止你重构。

通过类的公共API测试行为。不是实施细节。