测试驱动开发——让你的代码更简洁
原创- 发表时间 2021-02-03
- 阅读数 5948
- 最后编辑:程一凡 于 2024-07-03 09:56:11
盖房子时,工人师傅砌墙会先用桩子拉上吊线,以吊线为基准,以使砖能够垒的笔直。而测试驱动开发也是如此,先写一个测试,然后研发过程以此为基准,只编写能通过这个测试的功能代码。
顺序颠倒下,先垒砖,再拉吊线看墙面是否笔直,不直的话进行校正。这个过程就像传统的软件开发流程,先写功能代码,然后进行测试,有错误再一点点修改,因此,会严重影响研发效率。
测试驱动开发的目标
代码整洁可用,是测试驱动开发所追求的目标。但有很多因素会妨碍我们得到整洁的代码,甚至是可用的代码。
如何实现测试驱动开发?
1. 只有自动测试失败时,我们才重写代码;
2. 消除重复设计,优化设计结构
这两条规则实际上也蕴含了开发过程中所经历的阶段。 测试驱动开发的整个流程正是将目标拆分,先达到“可用”目标,再追求“简洁”目标。
测试驱动开发的流程
1. 首先思考并编写用于定义产品代码 行为的测试
2. 运行测试,发现新增的测试不能通过
3. 编写适当够用的代码
4. 运行测试,直至测试通过
5. 重构代码,以消除重复设计,优化设计结构
6. 运行测试,验证重构是否引入新的错误,直至测试通过且无需再重构
7. 最后重复上述步骤
测试驱动开发其实是戴两顶帽子思考的开发方式:先戴上实现功能的帽子,在测试的辅助下,快速实现其功能;再戴上重构的帽子,在测试的保护下,通过去除冗余的代码,提高代码质量。
测试驱动开发,要求测试可以完全自动化运行,在对代码进行重构前后,必须运行测试。这有助于编写简洁可用和高质量的代码,能快速响应变化,并加速开发过程。
测试驱动开发的三定律
定律一:在编写不能通过的单元测试前,不可编写生产代码。
测试驱动开发主张“测试先行”,这意味着我们必须先写单元测试,并且该单元测试必然失败,才能编写生产代码。
定律二:只允许编写刚好能够导致失败的单元测试,编译失败也属于一种失败。
测试驱动开发鼓励“简单设计”,以很小的增量进行开发,遇到设计问题时能够及时解决,不要期望一个测试能实现多个功能。
定律三:只允许编写刚好能够使得失败的单元测试通过的生产代码。
简洁,尽最大可能减少不必要的工作,也是敏捷基本原则之一。要避免盲目编写将来有可能需要的代码。
遵循了测试驱动开发的这三条定律,那所有代码都是可测试的了。“可测试”的另一个词是“解耦”,为了单独测试模块,必须将其分离,所以测试驱动开发强迫分离模块,迫使大家创建更好、更少耦合的设计。
Kent Beck最早在其极限编程方法论中,向大家推荐“测试驱动”这一最佳实践。极限编程中所有实践方法并不是独立的,而是相辅相成的。欢迎大家关注极限编程系列往期视频,了解更多极限编程实践方法。