大学IT网 - 最懂大学生的IT学习网站! QQ资料交流群:367606806
当前位置:大学IT网 > C#技巧 > 单元测试的一些常见问题总结

单元测试的一些常见问题总结

关键词:常见问题单元测试  阅读(1050) 赞(16)

[摘要]本文是对单元测试的一些常见问题总结的讲解,对学习C#编程技术有所帮助,与大家分享。

此文收集一些平时使用单元测试碰到的问题和解决办法,供大家参考。

如何检查返回的集合类是否符合期望?

Microsoft UnitTestFramework 如果需要元素的顺序一致,可以使用CollectionAssert.AreEqual;如果不需要考虑顺序,可以使用CollectionAssert.AreEquivalent。(有的地方说MSTest的Assert.AreEqual支持集合类型比较,我测试过,忽悠人的)
nUnit 同上
xUnit xUnit的Assert.Equal(c1, c2)可以支持集合类型比较,c1和c2的元素顺序必须一致

Microsoft UnitTestFramework / nUnit / xUnit 比较,使用哪个框架更合适?

Microsoft UnitTestFramework和nUnit的用法非常类似,而xUnit由于吸取了nUnit的设计上的经验,用法更加简洁。下面是周公写的两篇文章,nUnit和xUnit介绍的非常详细,大家可以阅读一下:

  • 在.NET开发中的单元测试工具之(1)——NUnit
  • 在.NET开发中的单元测试工具之(2)——xUnit.Net

什么是Mock?

单元测试的目标是一次只验证一个方法,小步的前进,细粒度的测试,但是假如某个方法依赖于其他一些难以操控的东东,比如说网络连接、数据库连接、系统时间、或者是Servlet容器,那么我们该怎么办呢?要是你的测试依赖于系统的其他部分,甚至是系统的多个其他部分呢?在这种情况下,倘若不小心,你最终可能会发现自己几乎初始化了系统的每个组件,而这只是为了给一个测试创造足够的运行环境让它们可以运行起来。忙乎了大半天,看上去我们好像有点违背了测试的初衷了。这样不仅仅消耗时间,还给测试过程引入了大量的耦合因素,比如说,可能有人兴致冲冲地改变了一个接口或者数据库的一张表,突然,你那卑微的单元测试的神秘的挂掉了。在这种情况发生几次之后,即使是最有耐心的开发者也会泄气,甚至最终放弃所有的测试,那样的话后果就不能想像了。

再让我们看一个更加具体的情况:在实际的面向对象软件设计中,我们经常会碰到这样的情况,我们在对现实对象进行构建之后,对象之间是通过一系列的接口来实现。这在面向对象设计里是最自然不过的事情了,但是随着软件测试需求的发展,这会产生一些小问题。举个例子,用户A现在拿到一个用户B提供的接口,他根据这个接口实现了自己的需求,但是用户A编译自己的代码后,想简单模拟测试一下,怎么办呢?这点也是很现实的一个问题。我们是否可以针对这个接口来简单实现一个代理类,来测试模拟,期望代码生成自己的结果呢?幸运的是,有一种测试模式可以帮助我们:mock对象。Mock对象也就是真实对象在调试期的替代品。

什么时候需要使用Mock?

关于什么时候需要Mock对象,Tim Mackinnon给我们了一些建议:

  • 真实对象具有不可确定的行为(产生不可预测的结果,如股票的行情)
  • 真实对象很难被创建(比如具体的web容器)
  • 真实对象的某些行为很难触发(比如网络错误)
  • 真实情况令程序的运行速度很慢
  • 真实对象有用户界面
  • 测试需要询问真实对象它是如何被调用的(比如测试可能需要验证某个回调函数是否被调用了)
  • 真实对象实际上并不存在(当需要和其他开发小组,或者新的硬件系统打交道的时候,这是一个普遍的问题)

如何使用Mock?

.NET Mock Framework有哪些,可以看看下面几个网页:

  • .NET Mocking Framework对比
  • What C# mocking framework to use?
  • The Fakes Framework in Visual Studio 2012

关于Mock框架的实现方式,大概有两种:基于动态代理实现;基于编译时静态织入实现。各个框架的用法看一下介绍很快就可以掌握了,关键是如何使用各种mock技术,存在的争论主要有下面几个:

  • 像Typemock、Moles、The Fakes Framework这类静态织入技术的框架,可以支持对Sealed Class、Non-Abstract Method、Non-Virtual Method、Static Method的Mock。有些人觉得这很强大,有些人觉得这反倒不好,他们认为像Moq、Rhino Mocks这类的框架,正因为不支持前面说的四类情况的mock,强迫项目必须实现依赖倒置,从而降低了项目的耦合性,以达到较高的可测试性以及可维护性。
  • 在使用动态代理方式的Mock框架时候,为了“可测试性”,protected方法必须是virtual的,因为我们需要在子类中进行override。同理,Mock框架能够辅助的方法也必须是virtual的,即使是一个public方法。那么,您觉得这是为了可测试性而做出的让步吗?或者换句话说,您觉得,一个不可以override的protected方法,但是会影响到其他公开接口的功能,这是不是一个合理的设计呢?如果这是一个合理的设计,又不想作出这样的让步……我们又该怎么做呢?(这段话摘自老赵的“与protected成员有关的单元测试方式”)
  • 在使用动态代理方式的Mock框架时候,为了测试一些Non-Abstract Method、Non-Virtual Method、Static Method,提供一个被测方法/类的Wrapper,封装对无法直接访问方法的调用,是否合适?做法参考:
    http://blog.zhaojie.me/2009/08/unit-test-protected-method.html#comment_iX2whQ8q04I003i2
    http://blog.zhaojie.me/2009/08/unit-test-protected-method.html#comment_iX2whQ8q04I003hi


参考:

  • 简​述​M​o​c​k
  • 使用Mono.Cecil解决无法Mock非虚方法和密闭类的问题
  • protected成员有关的单元测试方式
  • 如何 Mock 非虚方法和密封类?
  • 了解何时使用 Override 和 New 关键字(C# 编程指南)
  • C# 类教程-多态性


相关评论