走进单元测试四：单元测试背后的思考和感悟

最新推荐文章于 2024-11-14 20:53:43 发布

aimanbing4182

最新推荐文章于 2024-11-14 20:53:43 发布

阅读量106

点赞数

文章标签：测试数据库

原文链接：http://www.cnblogs.com/yangcaogui/archive/2012/02/11/2346428.html

版权

　　二月底就要完成所有的单元测试的任务了，做了将近三个月的时间，如果放在以前我有一肚子苦水要述说，不过经历了一些思想上的洗礼之后，不在那么单纯，只为把手头工作做的更加出色而已！

　这是单元测试最后一篇了，来做个总结把！　

目录：

　1.好的单元测试应该具备的特点　　　　　　　　　　　　　　　　

　　　　一个好的单元测试一定有它具备的特点，下面就来说说那些主要的特点！

　　　　主要概括为 → A-TRIP原则：

　　　　自动化　　→ Automatic

　　　　彻底性　　→ Thorough

　　　　可重复性 → Repeatable

　　　　独立性　　→ Indepentdent

　　　　专业性　　→ Professional

　　　　恰到好处的单元测试会使你的工作轻松，代码整洁干净，乱用，没有准则的用会浪费你大量的时间，不但没有效果还会是工期延误，所有了解单元测试很重要！

　　　　① 自动化

　　　　　　a) 不需要人的参与，有的时候只是轻轻的点击一个按钮就能自动执行，所以自动化的标志是不能比点击一个按钮的过程还要复杂！

　　　　　　b) 在签入其它的测试代码时不能对现有的代码造成影响！

　　　　　　c) 能够自动识别测试是失败还是成功(VS2008以后的版本都集成了这个功能)！

　　　　　　d) 在任何时候，任何地方都能自动运行(所以“Moles”技术就是关键)！

　　　　　　核心：执行测试代码和检查测试结果都必须自动化(VS2008以后版本都实现这个功能了)！

　　　　　总结：I，不要引入一个由于需要手动步骤而打破单元测试的自动化模型的测试！

　　　　　　　　 II，对于测试所需要的任何条件(大部分是数据库)都应该让它成为自动化测试的一部分，如果有需要可以使用Mole技术！

　　　　② 彻底性

　　　　　　所谓的彻底性就是说你的测试案例必须要考虑的全面，应该把可能出现的问题都做成测试案例！

　　　　　　具体从哪些方面着手，可以参数这篇：走进单元测试二：测试需要从哪些方面着手

　　　　③ 可重复性

　　　　　　a) 每个测试案例应该独立于所有的其它测试，而且必须独立于周围的(系统)环境！

　　　　　　b) 测试代码能够一次又一次的运行，在不修改代码的前提下都能产生一样的结果，否则有BUG！

　　　　　　c) 不要把测试代码写死，应该写的更加灵活一点，运用封装，重构等等的思想！

　　　　　　d) 不要让测试本身也出现BUG，确保测试代码的正确性！

　　　　④独立的

　　　　　　a) 每个测试应该有很强的针对性，也就说一个测试只能测试一个方面的内容！

　　　　　　b) 每个测试应该独立于环境(软件所处的系统环境)和其它测试！

　　　　　　总结：I，每个测试都不能够依赖于其它测试，你可以在任何时间运行这个测试而不受其它测试的影响，每一个测试都应该是一座孤岛！

　　　　　　　　　　II，所以测试一个函数都有很多个测试方法，只有这样才是真正的测试！

　　　　⑤专业的

　　　　　　a) 所谓的专业就是你的测试代码应该跟你的开发代码保持一样的风格，如：简洁明了，封装，解耦，不要出现“Hard Core”，要灵活一点！

　　　　　　b) 拒绝编写冗余的测试代码，千万要小心不要掉进这个陷阱，因为像我们这样的新手在初期都不会注意到这样的问题，所以我们要牢记在心里！

　　　　　　c) 遵循普遍规则：1.维护封装 2.降低耦合！

　　　　　　总结：不管怎么样你都应该认认真真的对待单元测试，代码的质量要求都应该跟开发代码同等水平，这是作为开发者必备的素质！

　2.单元测试的命名规范　　　　　　　　　　　　　　　　　　　　

　　　　在我们项目的中，可能需要测试的方法有成千上百个，而每一个测试方法都有可能写三个以上的测试案例，那么怎么来维护这么测试案例呢？

　　　　所以我们应该规范方法的命名方式，那么其他人在阅读你的测试代码时，直接通过方法名就能知道你的测试案例是测试哪个方面的了！

　　　　Note：单元测试案例类似于一个可执行文档，可以帮助其它的开发人员了解方法的作用！

　　　　在我们的项目中是这样规定的：方法名 + _ + 你测试是哪个方面的内容 + _ + 产生的结果！

　　　　下面我就举个列子，下面的测试方法命名就是针对这个函数来命名的，如：　　　　

1 　　　　 public DataSet GetDetails(int ID)
2         {
3            　　// 方法的作用：这个一个获取数据，并包装成一个DataSet的方法，传入的参数是一个bondAppID，那么我们怎么来设计案例和命名方法名呢？

5         }

　　　　①首先设计你的测试案例

　　　　　　看到这个方法我就会有这几个想法：1，最大值 2，最小值 3，刚刚好的值 4，随便一个值 5，还有的测试案例会随着你代码中的逻辑而产生！

　　　　　下面是我的测试案例以及方法名的命名，测试方法是上面的那个：　　　　　　

16         /// <summary>
17 　　　　 /// Input valid bond ,but the cheque is presented Status.
18 　　　　 ///</summary>
19         [TestMethod()]  //如果你预期有数据返回，那么就应该在最后面加上“RecordFound”，这样别人看的时候就能一目了然了！
20         public void GetDetails_CheckPresentedStatus_RecordFound()
21         {
22            //To Do.
30         }
31 
32         /// <summary>
33 　　　　 ///Cancel Status.
34 　　　　 ///</summary>
35         [TestMethod()]
36         public void GetDetails_CheckCancelStatus_RecordFound()
37         {
38            //To Do.
45         }
46 
47         /// <summary>
48 　　　　 /// Input max.
49 　　　　 ///</summary>
50         [TestMethod()]
51         public void GetDetails_CheckDetailsByMaxBoundaryValue_NoRecordFound()
52         {
53            //To Do.
59         }
60 
61         /// <summary>
62 　　　　 ///　Input min.
63    　　 ///</summary>
64         [TestMethod()]
65         public void GetDetails_CheckDetailsByMinBoundaryValue_NoRecordFound()
66         {
67            //To DO.
73         }
74 
75         /// <summary>
76 　　　　 /// Any bondID.
77 　　　　 ///</summary>
78         [TestMethod()]
79         public void GetDetails_CheckDetailsByAnyBondID_NoRecordFound()
80         {
81            //To Do.
89         }