第 13 章 单元测试
13.4. 正面测试 (Testing for success) 13.5. 负面测试 (Testing for failure) 测试有效输入还不够,还必需测试无效输入,而且要按预期失败形式执行 13.6. 完备性检测 (Testing for sanity) 测试的一条基本规则：每个测试用例只回答一个问题。 另一个基本规则：每个测试用例必须可以与其他测试用例隔离工作，每个测试用例是一个“孤岛”，降低测试间的藕合
第 14 章 测试优先编程
当所有测试都通过了，停止编程。
第 15 章 重构
不要怕麻烦，今天的单元测试就是明天的回归测试 (regression test) 15.2. 应对需求变化 全面的单元测试意味着不必依赖于程序员的一面之词 15.3. 重构
- 预编译正则
- 使用新的表达式，如： M?M?M?M? 替换为 M{0,4}
- 在正则里增加注释，使用re.VERBOSE 选项，告诉 Python 正则表达式里有内联注释，像下面这样
<pre> romanNumeralPattern = re.compile(''' ^ # beginning of string M{0,4} # thousands - 0 to 4 M's (CM|CD|D?C{0,3}) # hundreds - 900 (CM), 400 (CD), 0-300 (0 to 3 C's), # or 500-800 (D, followed by 0 to 3 C's) (XC|XL|L?X{0,3}) # tens - 90 (XC), 40 (XL), 0-30 (0 to 3 X's), # or 50-80 (L, followed by 0 to 3 X's) (IX|IV|V?I{0,3}) # ones - 9 (IX), 4 (IV), 0-3 (0 to 3 I's), # or 5-8 (V, followed by 0 to 3 I's) $ # end of string ''', re.VERBOSE) </pre>
15.4. 后记
- 可以考虑用查表法提高性能
- 单元测试给了你大规模重构的信心
15.5. 小结 单元测试是一个强大的概念，使用得当的话既可以减少维护成本又可以增加长期项目的灵活性。同样重要的是要意识到单元测试并不是“灵丹妙药”，也不是“银弹”。编写好的测试用例很困难，保持其更新更需要磨练。单元测试不是其它形式测试的替代品，比如说功能性测试、集成测试以及可用性测试。但它切实可行且功效明显，一旦相识，你会反问为什么以往没有应用它。
总结：
- 先写测试用例，再写实现代码
- 除了测试正确的结果，也要测试异常或错误的情况
- 为解决 Bug 或适应新需求而新增和升级测试用例。
- 为改进性能、可伸缩性、可读性、可维护性和任何缺少的特性而勇敢的重构代码。
来源：oschina
链接：https://my.oschina.net/u/618083/blog/206571