TDD的一些思考

前端之家收集整理的这篇文章主要介绍了TDD的一些思考前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

最近考虑在开发中引入TDD的概念,用于提高在进度压迫下的开发效率,搜索了一些资料,对于TDD的定义是这样的:

测试驱动开发
测试驱动开发(Test Driven Development,英文缩写TDD)是极限编程的一个重要组成部分,它的基本思想就是在开
功能代码之前,先编写测试代码。也就是说在明确要开发某个功能后,首先思考如何对这个功能进行测试,并完成测试代码的编写,然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能,直到完成全部功能的开发。代码整洁可用(clean code that works) 是测试驱动开发所追求的目标。

以上的定义一定程度阐述了TDD,只是如果将“测试代码”换成“测试用例”就会更加精确些,下面这个定义大家可以细细体会一下:

Test-driven design (TDD) (Beck 2003;Astels 2003),is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test andrefactoring.

TDD是一种演化后的开发方式,它结合了TFD,即在完成满足测试与重构要求的代码前,先编写测试用例。

这就要求测试人员要在项目的一开始(非开发开始)就要加入进来,测试人员除了提前写测试用例,无论是自动化的还是非自动化的,而需要测试人员参加的一项重要活动,就是参与特性验收条件的制定. 之前经常发生开发人员按照自己的理解去编码,测试人员按照自己的理解去测试,直到开发完成,测试过程中才发现理解的不一致,开始产生争执并阻塞等待产品经理或项目经理的仲裁. 解决办法就是就在开始开发新特性前的一刹那,由PM,测试人员,开发人员进行一次讨论,就验收条件达成一致并形成记录,然后测试人员和开发人员分头去写测试和实现。这里就体现了敏捷的特性----减少后期由于理解不一致的带来的成本消耗。

测试人员早期的加入还有一个好处,就是帮助开发人员设计制定“规则”。一份需求文档主要的工作是描述这个产品应该做什么,而测试人员编写的测试用例除了要检验“该做的有没有做”以外,另一个重要工作就是“不该做的是不是没做”。这就类似于是需求文档,甚至是设计文档的一种补充及检验。这样TDD就可以使开发人员在开发过程中就开始减少了引入的bug数目。这又是敏捷的另一个特性----减少了bug引入数,进一步减少了测试-修改的迭代次数,节省了时间与人力。

If it's worth building,it's worth testing.

If it's not worth testing,why are you wasting your time working on it?

原文链接:https://www.f2er.com/javaschema/287314.html

猜你在找的设计模式相关文章