④ 独立的
a)每个测试应该有很强的针对性,也就说一个测试只能测试一个方面的内容!
b)每个测试应该独立于环境(软件所处的系统环境)和其它测试!
总结:I,每个测试都不能够依赖于其它测试,你可以在任何时间运行这个测试而不受其它测试的影响,每一个测试都应该是一座孤岛!
II,所以测试一个函数都有很多个测试方法,只有这样才是真正的测试!
⑤ 专业的
a)所谓的专业就是你的测试代码应该跟你的开发代码保持一样的风格,如:简洁明了,封装,解耦,不要出现“Hard Core”,要灵活一点!
b)拒绝编写冗余的测试代码,千万要小心不要掉进这个陷阱,因为像我们这样的新手在初期都不会注意到这样的问题,所以我们要牢记在心里!
c)遵循普遍规则:1.维护封装 2.降低耦合!
总结:不管怎么样你都应该认认真真的对待单元测试,代码的质量要求都应该跟开发代码同等水平,这是作为开发者必备的素质!
2、单元测试的命名规范
在我们项目的中,可能需要测试的方法有成千上百个,而每一个测试方法都有可能写三个以上的测试案例,那么怎么来维护这么测试案例呢?
所以我们应该规范方法的命名方式,那么其他人在阅读你的测试代码时,直接通过方法名就能知道你的测试案例是测试哪个方面的了!
Note:单元测试案例类似于一个可执行文档,可以帮助其它的开发人员了解方法的作用!
在我们的项目中是这样规定的:方法名 + _ + 你测试是哪个方面的内容 + _ + 产生的结果!
下面我就举个列子,下面的测试方法命名就是针对这个函数来命名的,如:
1 public DataSet GetDetails(int ID) 5 } |
① 首先设计你的测试案例
看到这个方法我就会有这几个想法:1,最大值 2,最小值 3,刚刚好的值 4,随便一个值 5,还有的测试案例会随着你代码中的逻辑而产生!
下面是我的测试案例以及方法名的命名,测试方法是上面的那个:
/// <summary> /// Input valid bond ,but the cheque is presented Status. ///</summary> [TestMethod()] //如果你预期有数据返回,那么就应该在最后面加上“RecordFound”,这样别人看的时候就能一目了然了! public void GetDetails_CheckPresentedStatus_RecordFound() { //To Do. } /// <summary> ///Cancel Status. ///</summary> [TestMethod()] public void GetDetails_CheckCancelStatus_RecordFound() { //To Do. } /// <summary> /// Input max. ///</summary> [TestMethod()] public void GetDetails_CheckDetailsByMaxBoundaryValue_NoRecordFound() { //To Do. } /// <summary> /// Input min. ///</summary> [TestMethod()] public void GetDetails_CheckDetailsByMinBoundaryValue_NoRecordFound() { //To DO. } /// <summary> /// Any bondID. ///</summary> [TestMethod()] public void GetDetails_CheckDetailsByAnyBondID_NoRecordFound() { //To Do. } |