代码整洁之道【8】-- 单元测试

本章介绍了编写单元测试时候的一些要点。

敏捷和TDD（测试驱动开发）运动鼓舞了很多程序员编写自动化单元测试，但是许多程序员遗漏了一些关于编写好测试程序的更细微却重要的要点。

一、TDD三定律

①在编写不能通过的单元测试前，不可编写生产代码；
②只可编写刚好无法通过的单元测试，不能编译也算不通过；
③只可编写刚好足以通过当前失败测试的生产代码；

二、保持测试整洁

测试代码和生产代码一样重要。测试必须随着生产代码的演进而修改。

正是单元测试使得代码可扩展，可维护，可复用。没有单元测试的保证，就不敢放心地改动代码。测试使代码改动变得可能。

覆盖了生产代码的自动化单元测试能很大程度地保持设计和架构的整洁。有了覆盖率高的测试，可以毫无顾虑地改进架构和设计。

三、整洁的测试

整洁测试的三要素：可读性、可读性、可读性！
在单元测试中，可读性甚至比在生产代码更重要。
测试代码应该和生产代码一样，做到明确、简洁，有足够的表达力，呈现出构造–>测试–>验证的模式。

面向特定领域的测试语言：对于特定领域的测试，可以构造一些函数和工具代码来测试API，不用直接测试目标API；

四、每个测试函数只测一个概念

有的流派认为，Junit中，每个测试函数都应该有且只有一个断言语句（assert）。这条规则虽然有用但是过于苛求了。更好的做法是单个测试中断言的数量应该最小化，每个测试函数只测一个概念（一类场景）。

五、F.I.R.S.T

Fast–快速：测试应快速运行；如果测试运行缓慢，你就不会想要频繁的运行它，如果你不频繁的运行测试，就不能尽早发现问题，最终，代码就会变坏。

Independent–独立：测试间相互独立，不能有所依赖；某个测试不应为下一个测试设定条件。你应该可以独立运行每个测试，及以任何顺序运行测试。

Repeatable–可重复：测试应在任何环境中可重复通过；

Self-Validating–自足验证：测试应由布尔输出进行验证，无论通过还是失败，你不应该查看日志来确认测试是否通过。

Timely–及时：测试应及时编写。单元测试应该恰好在使其通过的生产代码之前编写。如果在编写生产代码之后编写测试，你会发现生产代码难以测试。

参考
《代码整洁之道》