1. TDD的简介
TDD 是敏捷开发中的一项核心实践和技术,也是一种设计方法论。TDD的原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。TDD 是 XP(Extreme Programming)的核心实践。
TDD 有广义和狭义之分,常说的是狭义的 TDD,也就是 UTDD(Unit Test Driven Development)。广义的 TDD 是 ATDD(Acceptance Test Driven Development),包括 BDD(Behavior Driven Development)和 Consumer-Driven Contracts Development 等。
2.TDD的编码方式与传统的编码方式
TDD编码方式:
- 先分解任务,分离关注点。
- 列出示例,用实例化需求,澄清需求细节。
- 写测试,只关注需求,程序的输入输出,不关心中间过程。
- 写实现,不考虑别的需求,用最简单的方式满足当前这个小需求即可。
- 重构,用手法消除代码里的坏代码。
- 写完,手动测试一下,基本没什么问题,有问题补个用例,修复。
- 代码整洁且用例齐全,信心满满地提交。
传统编码方式:
- 需求分析,比较难分析到清楚细节,但是时间问题,不得不按粗略的理解编码。
- 在编码过程中发现需求细节不明确,需要同业务人员进行需求确认。
- 可能需要确认多次需求才能实现业务逻辑。
- 一堆代码编写完后,在运行和测试时可能会出现很多bug,所以需要大部分时间去调试和修改。
- 转测试,QA 测出 bug,debug, 打补丁
3.使用TDD的好处
适当减少了开发者的工作量
通过明确的流程,让我们一次只关注一个点,思维负担更小,编码测试方便。
单元测试保证代码质量
TDD 的好处是覆盖完全的单元测试,为产品代码编写时提供了比较方便的测试,使得开发人员面对需求变化时比较方便的做出相应的修改,此外也能够方便的实现改善代码的设计。这样开发人员提交的代码质量就比较高。
方便理解业务需求
先写测试可以帮助我们去熟悉我们的业务需求,并提前发现需求细节,而不会时编码工作进行一半后才发现不明确的需求。
快速反馈
有很多人说 TDD 时,我的代码量增加了,所以开发效率降低了。但是,如果没有单元测试,就需要手工测试,这样就会花很多时间去准备数据,启动应用,跳转界面等,想要得到反馈的结果会比较慢。换言之,快速反馈是单元测试的好处之一。
4.TDD的三条规则
- 除非是为了使一个失败的 unit test 通过,否则不允许编写任何产品代码
- 在一个单元测试中,只允许编写刚好能够导致失败的内容(编译错误也算失败)
- 只允许编写刚好能够使一个失败的 unit test 通过的产品代码