0.摘要
本章继续深入前一章节的例子,通过更改需求—修改代码—重构这一流程让你逐步意识到单元测试的意义,以及它对重构的重要性。
1.新的错误
就算是竭尽了全力编写全面的单元测试,还是会遇到错误。我所说的“错误”是什么意思?错误是尚未写到的测试实例。
这段代码非常简单。通过传入一个空字符串调用 f r o m _ r o m a n ( ) from\_roman() from_roman() ,并确保其引发一个 I n v a l i d R o m a n N u m e r a l E r r o r InvalidRomanNumeralError InvalidRomanNumeralError 例外。难的是发现错误;找到了该错误之后对它进行测试是件轻松的工作。
用此方式编写代码将使得错误修正变得更困难。简单的错误(像这个)需要简单的测试实例;复杂的错误将会需要复杂的测试实例。在以测试为中心的环境中,由于必须在代码中精确地描述错误(编写测试实例),然后修正错误本身,看起来好像修正错误需要更多的时间。而如果测试实例无法正确地通过,则又需要找出到底是修正方案有错误,还数测试实例本身就有错误。然而从长远看,这种在测试代码和经测试代码之间的来回折腾是值得的,因为这样才更有可能在第一时间修正错误。同时,由于可以对新代码轻松地重新运行 所有 测试实例,在修正新代码时破坏旧代码的机会更低。今天的单元测试就是明天的回归测试。
2.控制需求变化
为了获取准确的需求,尽管已经竭力将客户“钉”在原地,并经历了反复剪切、粘贴的痛苦,但需求仍然会变化。大多数客户在看到产品之前不知道自己想要什么,而且就算知道,他们也不擅长清晰地表述自己的想法。而即便擅长表述,他们在下一个版本中也会提出更多要求。因此,必须随时准备好更新测试实例以应对需求变化。
举个例子来说,假定我们要扩展罗马数字转换函数的能力范围。正常情况下,罗马数字中的任何一个字符在同一行中不得重复出现三次以上。但罗马人却愿意该规则有个例外:通过一行中的 4 个 M 字符来代表 4000 。进行该修改后,将会把可转换数字的范围从 1…3999 拓展为 1…4999。但首先必须对测试实例进行一些修改。
现有的已知数值不会变(它们依然是合理的测试数值),但必须在 4000 范围之内(外)增加一些。在此,我已经添加了 4000 (最短)、 4500 (第二短)、 4888 (最长) 和 4999 (最大)。
“过大值输入” 的定义已经发生了变化。该测试用于通过传入 4000 调用 to_roman() 并期望引发一个错误;目前 4000-4999 是有效的值,必须将该值调整为 5000 。
“太多重复数字”的定义也发生了变化。该测试通过传入 ‘MMMM’ 调用 from_roman() 并预期发生一个错误;目前 MMMM 被认定为有效的罗马数字,必须将该条件修改为 ‘MMMMM’ 。
对范围内的每个数字进行完整循环测试,从 1 到 3999。由于范围已经进行了拓展,该 for 循环同样需要修改为以 4999 为上限。