单元测试
单元测试是那种确保程序“可运行”的用过就扔掉的代码，这种说法是错误的；我们会编写测试代码，确保代码中的每个犄角旮旯中都很好的运行
TDD三定律
- 在编写不能通过的单元测试前，不可编写生产代码
- 只可编写刚好无法通过的单元测试，不能编译也算不通过
- 只可编写刚好足以通过当前失败测试的生产代码
保持代码的测试整洁
- 脏测试等同于没测试
- 测试代码和生产代码一样重要
测试能够带来好处
- 单元测试可以让你的代码可扩展，可维护，可复用
- 覆盖了生产代码的自动化单元测试程序应该尽可能的保持设计和架构的整洁性
整洁的测试
面向特定领域的测试语言
- 打造了一套包装这些API的函数和工具代码，这样就能够更方便的写测试程序了，写出来的测试也更容易让人阅读。
双重标准
- 测试代码应该简单、精悍、足具表达力，他和生产代码一样有效
- 在生产代码中我们应该也避免使用StringBuffer，这样对cpu消耗有些大
每一个测试一个断言
- 单个断言是个好准则，我们应该遵守
- 最好的说法是单个测试中的断言数量应该最小化
F.I.R.S.T准则
- 快速（Fast):测试应该够快，如果测试运行缓慢，你就不会频繁的运行它
- 独立(Independent)：测试应该相互独立，某个测试不应该为下一个测试设定条件
- 可重复(Repeatable)：测试可在任何环境中重复通过
- 自足验证(Sele-Validating)：测试应该有boolean值输出。无论成功或者失败，不应该通过查看日志文件来确定测试是否通过
- 及时(Timely)：测试应该及时编写