很早就听闻过测试驱动开发,在加入ThoughtWorks之前,在参加ThoughtWorks University之前。但是一直都不得其法,没有登堂入室。这次从印度参加了“有史以来最好的一届”的TWU,顿悟了测试驱动开发(以下简称TDD),算是最大的收获。
其 实TDD很简单,只要你不把它当测试。没错,就这么简单。把TDD当测试来写,你想着的就是如何找出已有代码的错误。想象着的是一副从迷宫中拯救出受困公 主的图景。这个时候你就会受困于该如何去测与测什么的问题。假若你不把TDD当测试来写,顿时就会豁然开朗,拨云见日。
我认为TDD的本质在于, 通过写测试来写代码。也就是在每一行产品代码落笔之前,先写一个测试来给这行代码找一个存在的理由。在参加TWU期间,一位名叫Garret Smith的培训师(Coach)反复和我们强调任何一行代码都要有测试。而且给我们举了一个实际例子:公司的英国办公室的一位同事编写一个软件专门用来 对付无测试的代码。方式就是一行行地删除产品代码,如果测试仍然能够通过,这行代码就被删除了。这个例子给我的印象很深刻,因为我觉得它一语道破了天机。 TDD其实就这么简单,让你的产品代码不能随便被别人“删除”。
当用这个视角去实践TDD的时候。测试的名字就会很细节化。具体到描述什么条件时 以什么参数调用什么方法时会有什么返回值。回头一想,这些测试对应着是什么呢?其实就是javadoc文档!那么TDD又是什么一个过程呢?就是先写文档 再写代码的过程。这么一说来,TDD就很自然了。你先想到一个很简单的功能要实现,有很多的代码要写。从一堆要写的代码中选择出最简单的部分(比如边界的 情况)来写。把这部分代码的外部行为想好,写出对应的测试来,并给测试取一个能够当文档使的名字。
知道了TDD的本质与单元测试的本质之后,再来 看一下我认为唯一关键的一个实践,那就是Mock。没有Mock的单元测试就很可能不是单元测试,也许是集成测试,也许是功能测试,总之不是TDD中所需 要的那种能够驱动你开发的测试。任何牵涉到两个有行为的类之间交互的测试,都要Mock一个测另外一个,不然就会对象之间的互相影响就会使得测试测不准, 无法确知问题所在,也无法让你的测试能够清晰地表达意图。
也许以前有一些书籍或者人讲过TDD只适合测算法,单元测试要做到黑盒,写Mock要适 度之类的话。我目前的认识是这些见解容易让人把单元测试真当测试来看了。其实矫枉过正也无妨,就把TDD测试不当测试吧。总结一下就是TDD是确保你的代 码不被别人意外“删掉”的开发方式,单元测试是你产品代码的文档,Mock是编写单元测试时最重要的技术,用于隔离测试对象行为。
顿悟测试驱动开发
最新推荐文章于 2021-10-18 21:48:03 发布