老李分享：单元测试检查清单：让测试有效，避免致命错误 老李分享：单元测试检查清单：让测试有效，避免致命错误

老李分享：单元测试检查清单：让测试有效，避免致命错误

 

单元测试是测试你代码的一些经常使用方法集. 通常的操做步骤以下:

1. 先写北侧类的API

2. 测试对应API的方法名

3. 实现对应测试API的方法体

4. 运行单元测试

为何须要单元测试? 它能够测试现有的以及将来的功能模块. 保证代码质量. 它规范你书写具备可测性，低耦合的代码.这比手工回归测试廉价的多. 它将提升代码可行度.协助团队工做.

为啥须要个检查列表? 单元测试在实际操做时可能要复杂一点. 它须要你考虑清楚整个待测对象的框架. 但测试自己应该简单，直接，易用和易维护. 对于测试的开始点和结束点也要十分清楚.

使用这个检查列表能帮助你确保测试范围的有效性. 切记: 该列表能帮助你绕开那些明显的错误，但有前提:

□  一个测试类对应一个被测类.

• 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”，好比只有在一些边缘状况下，像等待通知或基于时钟的方法。