学以致用,单元测试的工具越来越多,可是想找一篇如何单元测试的文章却很难。所以偶来写一点自己的心得,也是一步步摸索着。
先从测试一个方法开始,偶随便找了一个小算法。这个方法看来正合适:不能太简单,比如一加一等于二;也不能太复杂,比如牵涉到数据库操作。
这个算法的功能是取得小于Max的N个随机不重复正整数,代码如下:
算法很好理解。好久前写的,现在翻出来,一眼就看出有问题。不过有点问题正好,看看单元测试能否找出来。
先添一个项目,引用NUnit.Framework,装好NUnit后在Net组件里有,免安装版的在解压后的目录里找。
新建一个Public类用于测试,叫Test,生成随机数的方法的类叫Program。现在无所谓,正式项目里命名得规范一点。Test类加[TestFixture]特性,添加一个Public函数叫做TestGetRandomNum,加上[Test]特性,这样NUnit就能认出这个方法是用于测试的方法了。还给该函数加了一个[Category("GetRandomNum")],因为一个功能可能要写几个函数来测试,这个特性表明方法属于测试GetRandom的方法组。
还有几个常用的特性: [TestFixtureUp] [TestFixtureDown] [TearDown] [Setup] [Ignore] [Explicit],据说以后了解这几个就差不多了。
接着,第一个测试方法该测试什么呢?以偶写代码的一点经验,每个函数都会把参数验证放在前面,参数无效就不往下走了,抛异常什么的该干嘛干嘛,那测试也先从参数测起吧。 现在分析一下参数异常下的输出:若N<1,不管Max值多少都返回空的List;若N>=1,且Max<N,由于Source集合数量不够,应该会引发IndexOutOfRangeException。
写一个测试方法用于测试这两种异常输出,应该写两个测试方法好一点。不过刚入手,一个两个就不必分了,写出来就好。代码如下:
运行NUnit加载项目,双击选中刚写的方法,眼前出现一根长长的大红条!
原来虽然是索引超出范围,但是泛型集合抛的却是ArgumentOutOfRangeException。火星了,MS为什么不和数组一样抛IndexOutOfRangeException异常呢?其实List中的元素也是存储在数组中的,我想MS是画蛇添足了。把catch语句改下异常类型,测试就通过了,其他和预想的都一样。
第一个测试方法就完成了。写测试看来还是有点麻烦,NUnit的工作只是将你测试类里的方法一起运行并显示结果。但测试用例和逻辑,都得自己写,只是参数验证还好说。下面要验证正常输出结果的随机性,就费了点功夫。
正常输出,应该验证这些:个数、范围、元素不重复、运行不重复、随机分布。
第二个测试方法只比较了一下两次运行不重复,这里就不把这个小算法抽象成机关重重的黑盒了,那应该测试个几百几千次,甚至更多,看结果的重复率。还有怎么高效地比较N个集合中,每个集合都很长很长,是否有元素完全相同的呢,我想可以对集合生成一个MD5签名再比较。
验证随机写在第三个验证方法里,和验证结果元素个数和范围在一起。关键来了,自己觉得它是随机的不行,怎么判断这些数是随机的?凭什么标准判断呢?要把判断的依据用编程语言告诉计算机。
随机数有什么特征,我思索着,终于总结出:随机就是不均匀又均匀。一个随机数,可以是在指定范围内任意值,此谓不均匀。但一次生成的一组随机数总体来看,若把总范围分成若干跨度相同的子范围,每个子范围内应有差不多数量的随机数。随机数总数越多,在各范围内分布的比例越接近,此谓均匀。说到分布,想起来了,我们中学就学过一个描述分布的数学概念:方差。我们生成的随机数,应对范围的中间值有一定的方差。而这个方差,应该接近于绝对均匀分布情况下的方差。我估计平均每次浮动在10%内,如果通不过,再调整一下。
验证随机分布部分代码如下:
这里采用循环生成测试参数,以后应该会经常用到这种方式。写完,生成项目,NUnit加载,Run,大红条!看来浮动范围限制得太小,但是一看NUnit Text OutPut栏,发现有的结果浮动值过于悬殊,达数倍之多。结果之间差别也很大,不对劲!
在项目里调试,一下子就发现,不,应该说是想起来:生成随机数的种子应该在循环外就初始化。不然,生成的全是连续的“随机数”。
做修改,NUnit重新Run一下,通过!这才是真正的随机数,随机得很暴力,平均方差浮动不到1%!
测试项目代码在这里,还有官方NUnit下载。单元测试也是程序开发的一部分,希望与大家一起学习交流,成为软件开发的现代化正规军。