演化架构与紧急设计: 测试驱动设计，第 2 部分

核心提示： 对于 TDD，我的经验规则是测试应该是潮湿的，演化架构与紧急设计: 测试驱动设计，第 2 部分(2)，但是不要湿透，也就是说， 常常被忽视的一种测试用例是边界条件：当遇到不正常的输入时，代码会做什么？围绕 getFactors() 方法编写一些测试，测试中可以有一些重复（而且这是不可避免的），但

对于 TDD，我的经验规则是测试应该是潮湿的，但是不要湿透。也就是说，测试中可以有一些重复（而且这是不可避免的），但是不应该创建笨拙的重复结构。因此，我要重构测试，提供一个 private 辅助方法，用它处理这个常用的创建语句，见清单 2：

清单 2. 保持测试适当潮湿的辅助方法
private　Set<Integer>　expectationSetWith(Integer...　numbers)　{　
　　return　new　HashSet<Integer>(Arrays.asList(numbers));　
}　

清单 2 中的代码能够让对因子的所有测试更加简洁，清单 1 中的测试可以改写为清单 3 这样：

清单 3. 更潮湿的数字因子测试
@Test　public　void　factors_for_6()　{　
　　Set<Integer>　expected　=　expectationSetWith(1,　2,　3,　6);　
　　Classifier4　c　=　new　Classifier4(6);　
　　c.calculateFactors();　
　　assertThat(c.getFactors(),　is(expected));　
}　

在编写测试时，也应该遵守良好的设计原则。测试也是代码，良好的原则也适用于测试（尽管原则有所差异）。

边界条件

在为一些新功能编写第一个测试时，TDD 鼓励开发人员编写失败的测试。这可以防止测试意外地通过所有情况，也就是说，测试实际上没有测试任何东西（同义反复 测试）。测试还可以检查您认为正确，但是没有经过充分测试的行为。这些测试不一定需要首先采用失败测试的形式（但是，如果在认为测试应该通过时测试却失败了，这是很有价值的，因为这意味着找到了一个潜在的 bug）。考虑测试会引导您考虑哪些东西是可测试的。

常常被忽视的一种测试用例是边界条件：当遇到不正常的输入时，代码会做什么？围绕 getFactors() 方法编写一些测试，可以帮助我们考虑合理和不合理的输入可能导致什么情况。