从开发的角度来讲,先把变量、函数按照一定的命名、格式组织好,接下来,开始编写代码,在业界,很多提倡测试驱动开发,接下和大家聊一下单元测试。
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、没有单元测试,即使如此,我们还是要坚持这一原则,慢慢往单元测试这个目标靠近...
你可能喜欢: