实践中的重构29_不自动的自动化测试

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

	@Test
	public 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来验证。