《代码整洁之道》第9章：单元测试——学习笔记

• 有了一套运行通过的测试，我会确保任何需要用到代码的人都能方便地使用这些测试。
• 确保测试和代码一起签入同一个代码包。
• 敏捷和TDD运动鼓舞了许多程序员编写自动化单元测试。

TDD三定律

定律一： 在编写不能通过的单元测试前，不可编写生产代码。
定律二： 只可编写刚好无法通过的单元测试，不能编译也算不过。
定律三： 只可编写刚好足以通过当前失败测试的生产代码。

• 这三条定律将你限制在大概30秒一个的循环中。测试于生产代码一起编写，测试只比生产代码早写几秒钟。
• 这样写程序，测试将覆盖所有生产代码。测试代码量足以匹敌生产代码量，导致令人生畏的管理问题。

保持测试整洁

• 脏测试等同于——如果不是坏于的话——没测试。
• 测试必须随生产代码的演进而修改。测试越脏，就越难修改。
• 测试代码和生产代码一样重要。它可不是二等公民。他需要被思考、被设计和被照料。它应该向生产代码一般保持整洁。

测试带来一切好处

• 没有了测试，你就会失去保证生产代码可扩展的一切要素。
• 正式单元测试让你的代码可扩展、可维护、可复用。
• 原因很简单。有了测试，你就不用担心对代码的修改！没有测试，每次修改都有可能带来缺陷。
• 没有了测试，你就很难做改动，因为你担忧改动会引入不可预知的缺陷。
• 有了测试，愁云一扫而空。测试覆盖率越高，你就越不用担心。

整洁的测试

• 三个要素：可读性、可读性和可读性。
• 在单元测试中，可读性甚至比在生产代码中还重要。
• 如何做到可读？和其他代码一样：明确，简洁还有足够的表达力。
• 在测试中你要以尽量少的文字表达大量内容。
  
• 这些测试显然呈现了构造-操作-检验模式。每个测试都清晰地拆分为三个环节：
• 第一个环节构造测试数据
• 第二个环节操作测试数据
• 第三个部分检验操作是否得到预期的结果

每个测试一个断言

• 单个断言是个好准则。
• 更好一些的规则或许是每个测试函数中只测试一个概念。

F.I.R.S.T.

整洁的测试还遵循以下5条规则：

• 快速：测试应该足够快。才能频繁的进行运行测试。
• 独立：测试应该互相独立。某个测试不应为下一个测试设定条件。
• 可重复：测试应当可在任何环境中重复通过。
• 自足验证：测试应该有布尔值输出。
• 及时：测试应及时编写。

总结

我们只是触及了这个话题表面。实际上，我应该为整洁的测试写上一本书。对于项目的健康度，测试和生产代码同等重要。获取测试更为重要，因为它保证和增强了生产代码的可扩展性、可维护性和可重复性。