从开发的角度来讲，先把变量、函数按照一定的命名、格式组织好，接下来，开始编写代码，在业界，很多提倡测试驱动开发，接下和大家聊一下单元测试。
TDD是测试驱动开发（Test-Driven Development）的英文简称，是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码。
1、TDD三定律
定律一 在编写不能通过的单元测试前，不可编写生产代码。
定律二 只可编写刚好无法通过的单元测试，不能编译也不算不通过。
定律三 只可编写刚好足以通过当前失败测试的生产代码。
测试与生产代码一起编写，测试只是比生产代码早写几秒钟。
2、保持测试整洁
测试代码和生产代码一样重要，一样需要保持足够的整洁。
测试带来一切好处。
整洁的单元测试代码会给你的代码带来很多好处。测试越脏，代码最终会变得越脏。如果丢失了测试，代码开始腐烂。
3、整洁的测试
整洁的测试有一个十分重要的要素：可读性。
测试代码要保持明确、整洁，还要有足够的表达力。在测试中，要以尽可能少的文字表达大量内容。
测试模式：构造-操作-检验，
第一环节 构造测试数据
第二环节 操作测试数据
第三环节 验证操作是否得到期望的结果。
3.1 面向特定领域的测试语言
使用测试的语言测试，更具可读性。
3.2 双重标准
测试API中的代码有着与生产代码不同的工程标准，要求应当简单、精悍、足具表达力，但又要和生产代码一般有效。
4、每个测试一个断言
有人认为每个测试函数都应该有且只有一个断言语句。
每个测试一个概念。
更好的规则或许是每个测试函数中只测试一个概念，只做一件事情。
5、F.I.R.S.T 原则
整洁代码应当遵循以下规则：
快速（Fast）测试应该够快。测试应该能快速运行。
独立（Independent)测试应当相互独立。某个测试不应为下一个测试设定条件。
可重复（Repeatable）测试应当在任何环境下中重复通过。
自足验证（Self-Validating）测试应该有布尔值输出。无论是失败还是通过，应直接了当得出结论，而不应该通过查看日志来确认测试是否通过。
及时（Timely）测试应及时编写。单元测试应该恰好在使其通过的生产代码之前编写。
6、小结
测试与代码同等重要，它保证和增强了生产代码的可扩展性、可维护性和可复用性。保持测试的整洁，让测试具有表达力并短小精悍。发明作为面向特定领域语言的测试API，帮助自己编写测试。
在实际的开发中，很多团队，由于各种外部、内部的因素，工期紧、时间少、任务重等诸多因素，很多事没有TDD、没有单元测试，即使如此，我们还是要坚持这一原则，慢慢往单元测试这个目标靠近...
你可能喜欢：
