测试驱动开发.ppt

测试驱动开发 1大纲? ? ? ? ? 2 ? ( Test Driven Development, 英文缩写 TDD )是极限编程的一个重要组成部分,它的基本思想就是在开发功能代码之前,先编写测试代码。也就是说在明确要开发某个功能后,首先思考如何对这个功能进行测试,并完成测试代码的编写,然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能,直到完成全部功能的开发。代码整洁可用(clean code that works) 是测试驱动开发所追求的目标。虽然 TDD 光大于极限编程,但测试驱动开发完全可以单独应用。 3 ? ,让客户全面参与软件的开发设计,保证变化的需求及时得到修正。要让客户能方便地与开发人员沟通, 一定要用客户理解的语言,先测试再编码就是先给客户软件的外部轮廓,客户使用的功能展现,让客户感觉到未来软件的样子,先测试再编码与瀑布模型显然是背道而驰的。同时,极限编程注重用户反馈与让客户加入开发是一致的,让客户参与就是随时反馈软件是否符合客户的要求。有了反馈,开发子过程变短,迭代也就很自然出现了, 快速迭代,小版本发布都让开发过程变成更多的自反馈过程。反馈迭代聆听测试编码设计 4 ? ,它有如下好处: ?(1)测试驱动开发最重要的功能还在于保障代码的正确性,能够迅速发现、定位 bug 。针对关键代码的测试集,以及不断完善的测试用例,为迅速发现、定位 bug 提供了条件。?(2)通过编写代码的测试用例,对其功能的分解、使用过程、接口都进行了设计。而且这种从使用角度对代码的设计通常更符合后期开发的需求。可测试的要求,对代码的内聚性的提高和复用都非常有益。因此测试驱动开发也是一种代码设计的过程。?(3)写单元测试的时候,很容易就可以为一个行为写一个测试用例,让它通过, 然后为另一种行为写另一个测试用例。也就是说,整个任务会被划分成很多小的任务,独立完成。如果我们不用 TDD 而直接实现的话,我们很容易就会同时把所有的行为都实现了。这样花的时间长,而且在这相当长的时间里面,写的代码都是没有测试过,不能保证准确性的。相反的,用 TDD 的话,我们只实现要测的行为的代码。它只花费很少的时间(几分钟),而且可以马上测试。 5 ?(4)为了更容易的写单元测试,我们会广泛的使用接口。这个会让单元测试代码很容易读跟写, 因为测试代码里面没有多余的数据。如果我们不用 TDD 而是直接写实现的话,我们经常会使用现成的类,测试为了调用现成的类, 就不得不创建很多多余的数据,创建很巨型的对象。?(5)因为广泛的使用接口,我们的类之间就不会藕合,因此重用性更好。?(6)发现比传统测试方式更多的 Bug 。?(7)完工时完工。表明我可以很清楚的看到自己的这段工作已经结束了, 而传统的方式很难知道什么时候编码工作结束了。 6 ? ?1)明确当前要完成的功能。可以记录成一个 TODO 列表。?2)快速完成针对此功能的测试用例编写。?3)测试代码编译不通过。?4)编写对应的功能代码。?5)测试通过。?6)对代码进行重构,并保证测试通过。?7)循环完成所有功能的开发。可参考《测试驱动开发》第 175 页 7 ? ?(1)测试隔离。不同代码的测试应该相互隔离。对一块代码的测试只考虑此代码的测试,不要考虑其实现细节(比如它使用了其他类的边界条件)。?(2)一顶帽子。开发人员开发过程中要做不同的工作,比如:编写测试代码、开发功能代码、对代码重构等。做不同的事,承担不同的角色。开发人员完成对应的工作时应该保持注意力集中在当前工作上,而不要过多的考虑其他方面的细节,保证头上只有一顶帽子。避免考虑无关细节过多,无谓地增加复杂度。?(3)测试列表。需要测试的功能点很多。应该在任何阶段想添加功能需求问题时,把相关功能点加到测试列表中,然后继续手头工作。然后不断的完成对应的测试用例、功能代码、重构。一是避免疏漏,也避免干扰当前进行的工作。?(4)测试驱动。这个比较核心。完成某个功能,某个类,首先编写测试代码, 考虑其如何使用、如何测试。然后在对其进行设计、编码。?(5)先写断言。测试代码编写时,应该首先编写对功能代码的判断用的断言语句,然后编写相应的辅助语句。 8 ?(6)可测试性。功能代码设计、开发时应该具有较强的可测试性。其实遵循比较好的设计原则的代码都具备较好的测试性。比如比较高的内聚性,尽量