单位测试是测试你代码的一些经常使用办法集. 普通的操纵步调以下:
先写北侧类的API
测试对应API的办法名
完成对应测试API的办法体
运转单位测试
为何需求单位测试? 它可以测试现有的和将来的功用模块. 包管代码质量. 它标准你誊写具有可测性,低耦合的代码.这比手工回归测试便宜的多. 它将进步代码可行度.协助团队任务.
为啥需求个反省列表? 单位测试在实践操纵时可能要庞杂一点. 它需求你思索明白全部待测工具的框架. 但测试自身应当容易,间接,易用和易保护. 关于测试的开端点和完毕点也要非常明白.
运用这个反省列表能协助你确保测试范畴的有效性. 切记: 该列表能协助你绕开那些分明的过错,但有条件:
□ 一个测试类对应一个被测类.
o 你要测试的是一个已声明的类的准确性.
□ 一次只测试一个办法体.
o 私有办法不需求测试! 它们是被封装起来的.
□ 测试的办法名和变量都是显示界说的.
o 比方,将预期后果保管到 expectedFoo 变量就比 foo好很多. 假如要测试非常多复合后果,可使用组合的称号inputValue_NotNull, inputValue_ZeroData, inputValue_PastDate, etc. (取决于你的代码标准).
□ 测试用例易于了解.
o 厥后的运用者将会很轻易了解测试代码的粗心而无需存眷太多的详细完成. 这能协助他们在调试之前晓得任务的大约内容.
□ 测试用例契合代码整洁标准.
o 测试用例中不要包括流程把持语句 (switch, if, 等.). 好的用例就是很间接的数据预备,后果验证进程.假如场景需求,可以配上测试桩来优化代码构造. 关于多场景测试,誊写多个对应的测试用例 (逐个对应).
o 比方,一个测试用例代码长度最幸亏 – 1 到20行摆布.假如测试代码太长,思索拆开成自力的小测试集,以免搅在一同.
□ 测试用例最好验证预期的异常.
o Java里用 @Test(expected=MyException.class).
□ 测试用例最好不要衔接到数据库.
o或许说,假如测试中需求衔接数据库操纵,就运用mock “在每次新的测试开端留意测试时的数据库衔接形态”衔接,断开 (运用 Setup/Teardown).
□ 测试用例最好不要衔接收集资本.
o 测试某个办法时没方法确保第三方的收集装备的有效性 (运用mocks).
□ 测试用例需求留意边沿效应,极限值 (max, min) 和null的处置(就算是在异常中抛出的也要留意).
o就算在测试里这些内容不需求被保护,我们也要确保这些问题不会呈现.
□ 测试用例不管在任什么时候候任何地方都无需人工干涉来履行.
□ 测试用例测试了以后的代码但也能很轻易的测试未来完成的代码.
o 测试就是为了确保代码的准确演化.假如没法易于扩大,那它就成烈?担. (非常多人不写单位测试用例就是这个缘由.)
□ 测试用例具有一致性.
o 在Java: 别运用 Date()作为被测办法的输出数据,最好运用Calendar (别忘了时区设置装备摆设). 再比方: 用name = “Smith”; 不要用 name = “name”; 或是name = “test”;
□ 测试用例运用mock来模仿庞杂的代码构造或办法体.
o 记着一次只测试一个类.
o 不要在本人的类中测试第三方的类库. 类库的测试交给它们本人的测试 (这也是辨别类库好坏的一条原则).
□ 不要注释掉测试用例 @ignored . 切记. 切记.
□ 测试协助我确保了全体的架构设计.
o 假如有阿谁办法没方法被测试,阐明设计的有问题.
□ 我的测试可以运转在任何平台,而非指定目的平台
别期望一个特定的装备或硬件设置装备摆设。不然你的测试会使迁徙更艰苦,这里鼓舞禁用它们。
□ 我的测试像闪电普通快!
慢的测试不该该把你拖垮。速度鼓舞你常常启动您的测试。它另有助于减少继续集成零碎上的构建工夫。
运用测试运转顺序,答应您在写测试时一次启动一个测试。要警惕运用“delay”和“sleep”,比方只要在一些边沿状况下,像等候告诉或基于时钟的办法。
2KB项目(www.2kb.com,源码交易平台),提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务