项目中经常遇到这样的问题,写好的模块,由于需求的变更,数据库字段进行了修改,逻辑也有些变更,于是乎,在一大堆代码修改后,进行运行界面开始测试。无奈一次不可能写对所有的逻辑,或者连字符都拼错。尤其是做B/S系统的时候,调试好一个功能,往往花费你大量的时间。而且,有更改的话,还要重来一遍,如果遇上些关联关系,调试测试就更加复杂了。并且,在项目做了N个模块后,又修改了一个功能,说实话,天知道其他逻辑是否产生BUG了没,呵呵。
所以,引进单元测试还是很有必要的,合理使用,还是很能够改进代码质量。看似CODE的时间延长了,实际上却大大的缩短了DEBUG时间,并且大大减少了修改功能影响其他方法的边际相应。
如果做是比较好的实践呢?
一般大家都使用Nunit,这个不难,随便园子里面、网上都能搜到很多入门文章,我也不在复述。只谈谈注意事项。
1.测试只需做到逻辑操作的测试、数据crud的测试就行了。前端ui数据的收集显示不是Nunit做的。我们的任务是确保传送给ui的数据是正确的就行了。
如图,在标准的demo中,我只进行了bll和dal层的测试
2. 测试数据库最好和平时使用的数据库分开,因为平时的测试数据并不能很好的解决自动化测试的问题,如上图,用app.config单独进行了库的配置(DEMO用的是同一个库)
3.测试数据根据情况进行构造和清理
有时候数据需要清理,但有时候不需要,因为做分类测试的话,有些数据保留比较方便,因此,尽量使用[Test,Category("xx")] 进行分类
4.跟据模块来测试提高效率和测试效果
通过分类测试,更容易的看出某个模块的问题,有时候,单独测试一个方法的数据并不能说明什么问题
5.结合TestDriven.net让你事半功倍,结合这类vs的add-in工具,测试变得更加方便了,nunit成了摆设,基本上打开他是为了看到绿色的进度条来爽一把。
6.void方法的测试,我的意见是,测试是否抛出异常,例如要测试下面这个Add方法:
![](https://www.cnblogs.com/Images/OutliningIndicators/ContractedBlock.gif)
则我可以这样测试
Code
不知道如何传附件了,demo工程传不上来。使用demo,需要安装entlib2.0以上版本,建议安装nunit和testdriven.net来体验一下
下载连接https://files.cnblogs.com/emilchan/MyCzbb.rar