Bill Venners与Martin Fowler的对话(测试驱动开发)

对话马丁·福勒(Martin Fowler)——第五部分:测试驱动开发
简介

在这部分,Fowler 描述了测试优先设计的从容品质,定义了何为单一思考,并且分析了单元测试和功能测试的区别。


逐步设计

Bill Venners:在进化型设计中,接口的设计是否是逐步完成的,每次只设计一小块?
Martin Fowler:没错。比如说,当我构造一个 Money 类时,在没实现“加法”功能之前,对于“乘法”功能我连考虑都不会考虑。只专注在“加法”功能上,不要想其它的事情。定义“加法”的接口,实现它的代码。然后再做下一步。
Bill Venners:我还是更习惯于这样的方式:好,让我们来看看 Money 这个类,它应该有哪些职责?需要提供哪些服务?先定义接口而不要管代码,把这些接口都定义清楚、一目了然,然后是写代码,接下来测试、实现,测试、实 现…… 我仍然倾向于把整个系统分为子系统,然后再分为子系统的子系统,然后批量地设计需要用到的接口,对于类也是如此。
Martin Fowler:我之所以采用逐步设计以及先写测试的方法,是因为这样做使我有了一个简明扼要的任务列表。在每个阶段的结尾,我都有一些已经做完的事情。于是我对自己说,好吧,这些东西是完成了的,把它们添加到已有的代码中吧。它们做了它们应该做的,而且是以正确的方式。


从容不迫的感觉

Martin Fowler:测试优先设计会使你体会到一种难以言传的从容不迫之感。你的进展其实非常快,但却不会让你感 到很紧张,因为你为自己设定的都是一些微目标(micro-goals)。在每个时间点上,你知道自己是在实现某一个微目标。一旦测试通过,该目标就实现 了。这是一种很平和的过程。它缩小了你的关注范围。你不需要去考虑每一件事情,只需要专注于某一小块功能。你实现了这个功能,然后重构它,使得其中每个环 节的设计都近于完美。然后再进行下一步。我以前用的是你所描述的方法,我不得不常常问自己,“这个东西的接口是什么?”而现在,我转向了增量式设计 (incremental design),并且觉得这种方式要大大由于之前的方法。
Bill Venners:好吧,我也会试试这种方式。
Martin Fowler:你只需要花少许时间来尝试一下。最好是跟以前这样做过的人在一起。只管做好了。
我在写《企业应用架构模式》(Patterns of Enterprise Applications Architecture Design)这本书的时候,曾碰到过这样一个增量式设计的例子。当时,我需要构建一个关联表映射(associative table mappings)的模式实例。假如在内存中你有一个多对多的关系,并且需要把它持久化到一个关系型数据库中。这时,你需要一个额外的连接表。因此一共有 三张表。有很多种方法可以将数据从数据库中读入到内存里:有一种比较简单的办法,但是需要执行多个 select 语句;也有一种比较快的方法,可以只用一个 select 语句,但是当需要把返回的数据提取出来并拆分到不同的对象中时,就会很别扭。
我用增量式设计构建了这个模式实例。起先,我针对三张具体的表和两个具体的类编写了一段写死的代码,根本就没有考虑通用化的问题。我只是 让这个非常特定、具体的例子能够运行起来。在通过测试之后,我着手重构这个例子以使它的应用范围更广一些。花了一点时间之后,我就得到了一个通用的机制。 我所要做的一切,就是写一个很小的映射类,就能够让这个例子对任意的表和类都适用。
我发现,从具体的实例入手然后再把它重构成一个抽象的例子是非常容易的;反之,如果从抽象的例子入手而把它应用到具体的案例中,则要困难 得多。我还发现,前者会给人一种更平静和从容的感觉,而实际的进展又非常之快。我能够始终清楚目前我在哪里,又在做什么。我对进度的把握也更加得心应手, 再也不会有那种“何时才能让这段代码运转起来”的无力感。


单一思考

Martin Fowler:Kent 在他的新书中与我不约而同地使用了同一个词——单一思考(monological thinking)。“单一”是指在任一时刻,都只使用一种逻辑,一种思考模式。当我构建前面提到的那个例子时,我只考虑如何使那个很具体的例子运行起 来;而当我进入到重构阶段时,我只考虑如何抽象化那个具体的例子。我不会同时去考虑两件事情;一次只做一件事情。我发现这样做的体验非常宁静而愉快。
Bill Venners:听起来似乎增量式设计是处理复杂性的一种解决之道,毕竟我们的大脑是有限的。那么,你认为先写测试或后写测试在多大程度上属于一种个人的选择?是否某些人天生适合一种,而某些人天生适合另一种?
Martin Fowler:这很有可能。人的个性很可能会有所差别。不过,现在还很难下结论,因为尝试过测试驱动开发的人还是少数。它在极限编程的人群中非常普及,但这部分人仍然只是程序员群体中极小的一片。
我建议你找个以前尝试过测试驱动开发的人陪你一起试试,这样你会有更好的体会,毕竟这与你平时的直觉是相反的。很抱歉我们没有时间做这个 尝试,尽管我是非常地愿意。我敢肯定,你会说,“我们干嘛要做这么小的一步?不值得这么做嘛!”而我则会说,“相信我。完成这些很细小的步骤。”这种情况 我见得太多了。我曾见过一个人第一次跟 Kent 一起编程。那个家伙研读过极限编程,并且对之很赞同。他应该是已经做好了充分的准备了。尽管如此,当他看到 Kent 所做的一些极细小的步骤时,下巴不止一次地掉了下来。最终他认识到,测试驱动开发完全不是他所期待的那样。


单元测试

Bill Venners:单元测试中的“单元”是什么意思?能给单元测试一个定义么?
Martin Fowler:哦,这很难。最粗略地讲,它是一个类。但随着你与之打交道越多,你就会意识到你是在测试功能 的一小块区域,而这一小块区域有可能是一个类的一部分,也有可能是几个类合起来的作用。我这里只是粗略地一说,不过,如果你想开始试试的话,可以把单元测 试看成是为每个类编写个测试案例。
Bill Venners:之所以把它称为“单元”测试,是因为你所做的测试是针对程序的单独的小块。为了使整个程序稳定运行,需要每个组成部分都能稳定运行;为了使每个组成部分稳定运行,则需要通过单元测试来对它们进行单独测试。
Martin Fowler:这是关于单元测试由来的解释。极限编程中的单元测试与传统的单元测试有所不同。在极限编程中,你并非割裂地去测试每个单元,而是去测试每个类及其与其他类的联结。
Bill Venners:单元测试和功能测试有什么不同?
Martin Fowler:在极限编程圈内,现在把功能测试称为验收测试(acceptance test)。验收测试更倾向于把系统视为黑箱,测试系统从端口到端口的表现。你可能会有针对在领域和数据库映射层中一些个体类的单元测试。这些单元测试 中,可能绝大部分都不需要连接数据库。你可能会把数据库排除在外。但是对于功能测试来说,当然是希望所有的东西都被联结起来。
Bill Venners:什么时候停止编写测试?你在《重构》一书中写道:“在某个节点,测试的回报会减小。编写过多的测试有可能使你感到沮丧,进而连一个测试都不写。你应该注意把握这个度。”那么,这个度在哪里?
Martin Fowler:这个要问你自己,程序中哪部分是你不希望发生变化的?我自己会做这样一个测试,问一问是否存 在程序中某行代码可以被注释掉而测试仍然可以通过的情况。如果有的话,或者是你少写了一个测试,或者是程序中有多余的代码。类似的,针对任何一个逻辑表达 式,是否可以将它取反?哪些测试会通不过?如果没有测试通不过的话,那么你显然需要再写一些测试,或者清除一些代码。
Bill Venners:听起来似乎可以将这个过程自动化。
Martin Fowler:事实上,有专门的程序做这个,叫 JesTer。问题是,它运行所需要的时间太长了。它每做一个小改动,就要把整个测试都重新生成一遍。

你可能感兴趣的:(Bill Venners与Martin Fowler的对话(测试驱动开发))