初试极限编程中的TDD

一、TDD的基本概念:

TDD是测试驱动开发,是极限编程中的实践,要求项目的测试先行,用测试来提高项目的整体质量与保证功能的完整性。

二、TDD的流程:

1)得到项目的一个需求。

2)针对这个需求编写相应的测试代码,包括正例和反例(正确的结果和错误的结果都需要有测试)。

3)运行编写的测试代码(保证测试代码没有语法上的错误,然后一定会报错,因为还没有相应的功能代码)。

4)根据测试中的内容,编写相应的controller代码(功能代码)。

5)再次运行测试代码,并修改controller代码,直到所有的测试全部都过。

第五步通过的时候我们就认为所有编写的controller代码都是正确的(由我们编写的代码运行正确来保证)。

三、TDD的注意点:

1)测试之间的隔离:

  • 一个项目的需求很多,会有很多的测试文件,那么TDD要求我们尽量保证测试之间是没有联系的,类似于要把代码耦合度降到最低。
  • 如果需要用到测试数据,比如需要测试的数据库数据,那么尽量降低数据之间的联系,不然当测试文件多起来的时候就很难维护。

2)测试流程的保证:

先写测试然后再编写功能代码。那么有人会问,功能代码都没有怎么写测试文件?

对于这个问题,我的理解是测试先行,是让我们先扮演用户的角色,而不是开发人员。我们得首先知道作为一个用户想要的是什么,想要得到什么数据、什么样的用户界面。所以对于一个测试第一次运行的时候肯定是错误的,因为没有相应的controller代码。但是你可以通过这个测试代码来确保你接下来要编写的controller代码需要什么参数、最终返回的结果是什么样的。正是通过这个机制,才能最大程度的保证代码的质量以及代码的实用性。

四、TDD的优点:

1)明确需求的完成程度:

没有测试的话,很多时候会不明确这个需求是否已经完成,没有一个标准去衡量这个需求是否已经完成。而有了TDD的测试后,只要测试全部通过了,那么就代表当前的需求已经完成,可以继续进行下一个需求。

2)解决软件编程中的需求不明确问题:

很多的软件项目是没有明确的需求的,客户很大的可能会随时改变需求,那么如何保证不会耗费过多的时间在可能随时会变的需求上呢?

以下两点可以一定程度上解决需求不明确的问题:

  • 第一个要求当然是TDD,用TDD保证更改当前需求的代码后不会影响项目中其它的功能。
  • 第二个是最小的需求,把需求拆分成最小可执行的模块,并用TDD的模式来完成,那么即使需求更变,那么只要付出最小的代价去实现新的需求。

3)代码文档的替代者:

TDD的测试文件是最好的api文档,甚至都不需要查看相应的接口文档,开发人员能从测试文件中看到更全面的接口信息,而不用去查文档,个人更喜欢直接看代码而不喜欢查看文档。

4)保证代码的质量

对于很多开发人员而言,最怕出现的就是代码的bug。有了测试文件之后,至少你可以保证有测试的功能是完全正确的。当然,你要经常更新测试文件来提高测试的覆盖率。

5)有利于维护:

如果修改了数据库中的某些数据字段,那么TDD就能帮助你找出其它影响的地方,而不用手动的去查找,提高维护的效率。

五、个人的一些疑问:

TDD测试能很大程度的保证代码的质量,那么对于一个需求的测试如何来保证你的测试是全面的,能把方方面面的各种情况都能写到测试中去,从而保证项目的质量,减少bug的出现,也就是如何提高测试的覆盖率。

发表评论

电子邮件地址不会被公开。 必填项已用*标注