您的位置:首页 > 产品设计 > UI/UE

Nunit--测试和项目结合的几种方法

2008-05-11 12:44 232 查看
<script type="text/javascript"><!--
google_ad_client = "pub-1592932103935230";
/* 336x280,csdnblogs, 创建于 08-5-10 */
google_ad_slot = "8315096772";
google_ad_width = 336;
google_ad_height = 280;
//-->
</script> <script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>
1、单元测试代码,直接写在需要被测试的类中。
 
   这种方法的优点很明显:由于测试代码同被测试的方法放在一个类中,所以private等方法很容易被测试。但同时缺点也很明显,该类会被写得很复杂,估 计很少会有人喜欢看这种代码,而且万一客户不需要这些代码的话,在最后部署的时候,关del测试代码,估计也是个大问题。
 
  2、每写一个需要被测试的类,就写当前工程下新建一个相应的测试类,名字可以在被测试类后面加上Test以示区别。
 
  这种方法的优点是结构比较清晰,在比较小的工程中使用还算不错,修改测试代码也比较方法。缺点同样是部署时删除单元测试代码比较麻烦,同时solution太大,有很多project时,有很大局限性。
 
  3、solution有很多个工程时,专门新增加一些工程,用于写单元测试,比如有一个ClassLibrary3工程,则建一个TestForClassLibrary3工程,单元测试类放到这个工程中去。
 
  由于是以工程为单位,所以部署起来很容易,只要把这几个工程去掉就可以了,将来再要用,也只要加上就可以了。不过操作相对来说比较繁琐,没有前2种方法便捷。
 
   4、以上3种方法都需要在项目的solution中增加东西,但如果你的项目不允许你增加任何测试类或工程(虽然感觉很愚蠢,但的确很多公司不允许程序 员这么做),或者你根本没有权限增加工程或文件,这3种方法将都不能使用,这时可以用第4种方法。比如你想测试ClassLibrary3工程下的 Class1类,你可以先build你的项目,生成ClassLibrary3工程的dll文件,然后在你本地建一个测试工程,引用这个dll,就可以不 需要修改你的项目了。
 
  这种方法的最大优点是不需要修改你的项目,不过缺点也很多,不够灵活,操作复杂等。
 
  我个人比较多用2,3,在很小的模块中有时会用1,不过比起用1来,可能使用TestDriven.NET更加方便些。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息