实践中的复建29_不自动的自动化测试

实践中的重构29_不自动的自动化测试
测试的精髓之一就是自动化。把一切可以自动化的东西都自动化起来，从而节约宝贵的人力，极大的提高效率。
看一个UnitTest的实现如下：

@Testpublic void test() {Date start = DayUtil.parseDate("20110101");Date end = DayUtil.parseDate("20110110");Map<Date, DayOrderStat> result = orderQueryService.queryUserOrderStat("normalUserId", start, end);result = orderQueryService.queryUserOrderStat("emptyUserId", start, end);result = orderQueryService.queryUserOrderStat("exceptionUserId", start,end);Assert.assertNotNull(result);}

该UT是一个接口的对应UT代码。原接口如下：

public interface OrderQueryService {/** * 按日查找用户的订单统计信息。 *  * <pre> * 该方法划分日订单为以下情况： * 1 一日有订单，则返回正常的Day,DayOrderStat对。 * 2 一日无订单，则返回Day,null对。 * 3 一日订单系统异常，则结果中不包含该日的订单统计信息。 * </pre> * */public Map<Date, DayOrderStat> queryUserOrderStat(String userId,Date start, Date end);}

当联调过程中发现该接口有异常时，一不小心看到了这个UT。开发人员打开IDE，加上断点，开始单步执行该UT来追踪哪里出现了问题。
看到本应该由UT完成的任务现在是由人工完成，明显的，该UT没有起到UT的作用。
该UT不符合一般UT的编写范式和原则，决定了该UT不能自动化验证方法的实现是否正确，同时，当出现问题时，UT也不能帮助开发快速定位问题。
一般UT的编写范式：
1 建立UT的执行环境。
2 执行要测试的方法。
3 验证结果。
或者基于契约的编写范式：
1 建立UT的执行环境。
2 验证方法调用的前条件满足。
3 执行要测试的方法。
4 验证结果。
这里的UT违反了UT的一个基本原则，隔离性。
一个方法如果有多个执行路径，则不同的执行路径可以用不同的UT来验证。

查看更多 下一篇