什么是单元测试?
单元测试(Unit Testing)是针对最小的可测试软件元素(单元)的,它所测试的内容包括单元的内部结构(如逻辑和数据流)以及单元的功能和可观测的行为。通俗一点讲,就是我们编程的时候,编写的一个测试方法用于检测功能是否正确的代码段,通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。
比如我们在编写代码的时候,写一个功能的实现代码,然后再编写一个Test方法用于测试这个功能的代码正确性,其实这个Test方法就是单元测试,又如在制造飞机的时候,通常会先生产飞机的零部件,然后再把这些成千上万的零部件进行组装,但是在组装之前,通常会对每个飞机零部件进行测试,通过了才能称为真正的飞机零部件,这个零部件测试其实就是“单元测试”。换个角度思考,如果再飞机组装后再进行测试,你会发现这是多么的愚蠢,这也说明了“单元测试”的重要性。
一般认为,在结构化程序时代,单元测试所说的单元是指函数,在当今的面向对象时代,单元测试所说的单元是指类。以类作为测试单位,复杂度高,可操作性较差,因此仍然主张以函数作为单元测试的测试单位,但可以用一个测试类来组织某个类的所有测试函数。单元测试不应过分强调面向对象,因为局部代码依然是结构化的。单元测试的工作量较大,简单实用高效才是硬道理。
有一种看法是,只测试类的接口(公有函数),不测试其他函数,从面向对象角度来看,确实有其道理,但是,测试的目的是找错并最终排错,因此,只要是包含错误的可能性较大的函数都要测试,跟函数是否私有没有关系。
注:上面部分概念来源百度百科。
为什么使用单元测试?
为什么使用使用单元测试?简单来说,原因就像孕妇做“胎前检查”一样。我们在开发项目的过程中,做某一模块的功能,代码写完了,然后生成一下就丢给测试人员去测试,最后测试人员就提出一大堆的Bug,虽然代码的语义上没有问题,但是并不代表代码实现功能没问题,这时候就需要做“单元测试”了,在提交给测试人员之前确保“代码功能”实现没有问题,当然需求错误就是另一方面的问题了,这是“单元测试”所测试不了的。
关于“单元测试”,很多程序员很少主动的去做,至少我是这样,为什么?
太麻烦了
花费太多时间
只是说明代码没有问题
我写的代码肯定没问题
上面几条一般是我们抵制“单元测试”的几个主要原因,说白了,就是我们太自信、太懒了,关于“单元测试”的好处就不多说了,就像上面的例子一样,如果你不做“胎前检查”,等到你的孩子生下来身体有所“缺陷”,你后悔也来不及,这也就是使用“单元测试”的原因。
NUint使用详解
NUint是我们做“单元测试”常用框架之一,官网地址:http://www.nunit.org/,官网上也提供相关文档,可以下载参考下:NUnit-2.6.3-docs.zip,NUint在项目中的安装使用主要有三种方式:
NUnit-2.6.3.msi:程序包安装,会添加到注册表,这个在配置VS的时候会用到。
NUnit-2.6.3.zip:压缩包解压,需要在项目中添加NUint引用。
NuGet安装命令:install-package nunit。
示例
关于NUint的使用,先贴一段最简单的“单元测试”的代码:
[TestFixture] 2 public class Test1 3 { 4 [Test] 5 public void TestMethod() 6 { 7 Assert.AreEqual("1", "2"); 8 } 9 } |
属性
可以看到在测试类和测试方法前有TestFixture和Test属性,TestFixture表示需要测试的类,也就是说测试的单元,Test表示测试用例,也就是测试方法,NUint中的TestFixture和Test属性是我们最常用的属性,当然除了他们俩之外NUint还提供了其他的一些属性,用来标注测试。
关于NUint的属性详细使用可以去官网的说明文档中查看,除了TestFixture和Test属性常用外,还有几个用于测试用例初始化的属性:
TestFixtureSetup:在当前测试类中的所有测试函数运行前调用;
TestFixtureTearDown:在当前测试类的所有测试函数运行完毕后调用;
Setup:在当前测试类的每一个测试函数运行前调用;
TearDown:在当前测试类的每一个测试函数运行后调用。
TestFixtureSetup对应TestFixtureTearDown,Setup对应TearDown,Setup在AutoMapper源码使用如下,用于AutoMapper的初始化:
[SetUp] 2 public void SetUp() 3 { 4 Mapper.Reset(); 5 } |
断言
从我们一开始贴的简单测试示例中可以看出,除了TestFixture和Test属性,还有就是这段代码:Assert.AreEqual("1",
"2");,这就是NUint的另一个概念-断言,什么是断言?”断“是判断的意义,”言“可以看做是测试用例的描述,也就是说用于测试用例的判断,如上段代码就是判断”1“和”2“是否相等,NUint常用断言:
简单测试
如果NUint安装好了,测试用例也编写好了,下面我们就要使用NUint进行”单元测试“了,如果选用的是NUint安装程序,我们可以直接在桌面打开”nunit.exe“程序,先生成一下我们编写的测试用例,可以是类库项目也可以是应用程序,然后在打开的NUint程序中选择:”File“-”Open
Project“,选择生成的dll或是exe,打开后点击”Run“就开始测试了:
从测试结果看出,我们编写的测试用例是不通过的,因为”1!=2“,在测试结果中会有错误提示,比如:Expected:
"1",But was: "2",我们修改下测试用例:
Assert.AreEqual("1", "1");,然后再生成下,看下测试结果:
从测试结果看出,我们编写的测试用例是测试通过的,因为”1=1“,这边注意一下,如果我们指定了测试dll或是exe,在生成后,不需要重新打开项目,直接可以点击”Run“进行测试,因为我们在编写代码的时候就进行”单元测试“了,这种常规的测试队程序员来说很不方便,我们希望可以再VS中集成NUint,这样就可以在编写代码的过程中很方便的进行”单元测试“了,怎么配置?请接着往下看。
External Tools
”扩展工具条“这种方式只是在VS中可以方便打开NUint程序,其实并没有方便多少,但是还是比上面常规方式奥方便些。
在VS中按下面方式配置:工具-外部工具,打开后添加如下命令:
命令:NUint的安装路径,参数:(TargetName)表示目标文件路径,(TargetExt)表示目标文件扩展名,初始目录:$(ProjectDir)表示当前程序的物理路径,后面加”\bin\Debug“,也就是表示当前项目的生成路径。点击确定后,在工具条中会发现多了”NUint“工具:
这边需要注意的是,在点击”NUint“这个工具之前,需要在代码窗体中打开需要测试的项目,比如当前代码窗体是”Class.cs“,那么打开”NUint“工具条,自动打开的就是”Class.cs“所在的项目。
Visual Nunit 2010
Visual Nunit 2010是NUint在VS的扩展插件,注意此插件只适用VS2010,下载地址:http://visualstudiogallery.msdn.microsoft.com/c8164c71-0836-4471-80ce-633383031099,安装后需要重启VS,打开:视图-其他窗口-Visual
Nunit,或者按”Ctrl+F7“快捷键打开:
打开Visual Nunit后,会有几个选项:Project、Mamespace和Fixture,分别表示测试项目、测试项目命名空间和测试用例,还是上面的示例,适用Visual
Nunit插件测试结果:
NUnit Test Adapter
通过上面Visual Nunit的使用,你会发现其插件还是蛮好用的,但遗憾的是只支持VS2010,找”Visual
Nunit 2012“找了好久也没找到。最后发现,在VS2012中使用Nunit变了一种方式,就是NUnit
Test Adapter,什么意思?顾名思义,就是NUnit测试适配器的意思,网上有人说使用”NUnit
Test Adapter“,测试项目必须是微软的”单元测试项目“,我试了下类库和应用程序都是可以测试的。
使用”NUnit Test Adapter“,需要在VS2012中添加其扩展:工具-扩展和更新-联机-搜索”NUnit
Test Adapter“:
安装完成后,在测试-窗口-测试资源管理器中打开其窗口,还是我们上面的测试用例,测试结果:
后记
示例代码下载:http://pan.baidu.com/s/1nt0oKUP
关于“单元测试”,以及NUint几年前都存在了,奈何小菜现在才开始接触,只恨自己生于太晚,但也为时未晚,本篇都是一些基础的知识或配置,希望大神们看到莫笑,如果能帮像菜鸟我一样的你,那真是莫大荣幸,本篇也只是开始,接下来会在项目中使用“单元测试”,到时候再做些总结或感想与大家分享,还请关注。
|