单元测试.net在VS2012中的最佳选择

本文关键字:最佳选择 VS2012 net 单元测试 | 更新日期: 2023-09-27 18:19:16

在阅读了这个网站上关于这个主题的几个帖子之后,我得出了以下结论:

要测试私有方法,有两种选择:

  • 使用PrivateObject,但是VStudio 2012的测试工具在进行大量测试时是蹩脚的,建议使用NUnit代替,但是PrivateObject使用的命名空间与NUnit的命名空间相冲突,例如,对于断言,因此,应该避免使用。

  • 转换受保护成员(属性+方法)中的所有私有成员,使包装类继承被测试的类,并通过public方法调用受保护的方法。

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

我不是要求讨论是否应该测试私有方法(这一点已经在其他线程中讨论过了),或者使用其他工具,或者捍卫VStudio (idem)。

我更想听听你对牺牲面向对象原则而不是可测试性的看法。

谢谢。

单元测试.net在VS2012中的最佳选择

我不明白为什么要测试私有方法。在我看来,您不应该仅仅为了测试私有方法而违背OO原则。为什么?因为您可能会破坏某些功能/架构,或者更糟,通过增加您的应该是私有方法的可见性而危及安全性。

只有公开的API(公共的)应该进行单元测试。因为这些方法是唯一可以看到并且可以在任何地方访问的方法。任何私有的东西都由这些公共方法使用。这些方法代表你的业务流程,API。因此,只测试公共方法是有意义的,因为这些方法将被并且可以被外部访问。

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

我至少是从OO范式的角度来说的。当然,会有争论认为单元测试更适合于过程/模块化范例,因为单元测试,根据其纯粹的定义,是测试系统的每个单元。

每当我测试私有方法时,我就在测试项目中编写了一个基于反射的扩展方法,并使用它来暴露函数,因为该方法只是起点,它在那里发生的事情是您对测试感兴趣的,所以如何并不像为什么在这种情况下那么重要。很多时候人们会说,如果某个东西是私有的,那就有问题,它应该在自己的类中,因为它有自己的责任等等,但是你可以稍后担心为什么…

无论如何,至于工具,我建议远离MSTest或微软集成测试框架,而选择像Nunit等开源工具。

这主要是因为在很多情况下,您希望自动构建并在构建服务器上运行它们,例如teamcity或jenkins(或者在一些罕见和疯狂的情况下TFS)。但是,如果您尝试在构建服务器上运行基于MSTest的测试,它将不允许您不安装visual studio,因为测试所需的dll保存在那里。所以我不认为你的构建服务器应该有你的IDE安装只是为了运行一些测试,所以在这种情况下,它是有意义的使用的东西是独立的和简单的,如Nunit,然后你只需要dll和运行器,工作完成。

== Edit ==

如果你决定通过反射(扩展或硬编码)来获取你的私有方法,这里有一个链接,它应该显示我的意思:

如何使用反射来调用私有方法?

我不会费心改变你的代码,因为你有它私有的原因(无论是对还是错),所以你不妨花5分钟做一个扩展方法和做你的测试,然后如果你意识到它私有是一个问题,你只是在你的测试中删除扩展调用。

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

这显然是个意见问题。然而要唱反调…为上述方法2辩护。

通常测试私有方法比测试公共API更简单,因此可以让您进行更小,更严格的测试,您可以更有信心。

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

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

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