单一思考

　　马丁：Kent 在他的新书中与我不约而同地使用了同一个词——单一思考（monological thinking）。“单一”是指在任一时刻，都只使用一种逻辑，一种思考模式。当我构建前面提到的那个例子时，我只考虑如何使那个很具体的例子运行起 来；而当我进入到重构阶段时，我只考虑如何抽象化那个具体的例子。我不会同时去考虑两件事情；一次只做一件事情。我发现这样做的体验非常宁静而愉快。

　　比尔：听起来似乎增量式设计是处理复杂性的一种解决之道，毕竟我们的大脑是有限的。那么，你认为先写测试或后写测试在多大程度上属于一种个人的选择？是否某些人天生适合一种，而某些人天生适合另一种？

　　马丁：这很有可能。人的个性很可能会有所差别。不过，现在还很难下结论，因为尝试过测试驱动开发的人还是少数。它在极限编程的人群中非常普及，但这部分人仍然只是程序员群体中极小的一片。

　　我建议你找个以前尝试过测试驱动开发的人陪你一起试试，这样你会有更好的体会，毕竟这与你平时的直觉是相反的。很抱歉我们没有时间做这个 尝试，尽管我是非常地愿意。我敢肯定，你会说，“我们干嘛要做这么小的一步？不值得这么做嘛！”而我则会说，“相信我。完成这些很细小的步骤。”这种情况 我见得太多了。我曾见过一个人第一次跟 Kent 一起编程。那个家伙研读过极限编程，并且对之很赞同。他应该是已经做好了充分的准备了。尽管如此，当他看到 Kent 所做的一些极细小的步骤时，下巴不止一次地掉了下来。最终他认识到，测试驱动开发完全不是他所期待的那样。

　　单元测试

　　比尔：单元测试中的“单元”是什么意思？能给单元测试一个定义么？

　　马丁：哦，这很难。最粗略地讲，它是一个类。但随着你与之打交道越多，你就会意识到你是在测试功能 的一小块区域，而这一小块区域有可能是一个类的一部分，也有可能是几个类合起来的作用。我这里只是粗略地一说，不过，如果你想开始试试的话，可以把单元测 试看成是为每个类编写个测试案例。

　　比尔：之所以把它称为“单元”测试，是因为你所做的测试是针对程序的单独的小块。为了使整个程序稳定运行，需要每个组成部分都能稳定运行；为了使每个组成部分稳定运行，则需要通过单元测试来对它们进行单独测试。

　　马丁：这是关于单元测试由来的解释。极限编程中的单元测试与传统的单元测试有所不同。在极限编程中，你并非割裂地去测试每个单元，而是去测试每个类及其与其他类的联结。

　　比尔：单元测试和功能测试有什么不同？

　　马丁：在极限编程圈内，现在把功能测试称为验收测试（acceptance test）。验收测试更倾向于把系统视为黑箱，测试系统从端口到端口的表现。你可能会有针对在领域和数据库映射层中一些个体类的单元测试。这些单元测试 中，可能绝大部分都不需要连接数据库。你可能会把数据库排除在外。但是对于功能测试来说，当然是希望所有的东西都被联结起来。

　　比尔：什么时候停止编写测试？你在《重构》一书中写道：“在某个节点，测试的回报会减小。编写过多的测试有可能使你感到沮丧，进而连一个测试都不写。你应该注意把握这个度。”那么，这个度在哪里？

　　马丁：这个要问你自己，程序中哪部分是你不希望发生变化的？我自己会做这样一个测试，问一问是否存 在程序中某行代码可以被注释掉而测试仍然可以通过的情况。如果有的话，或者是你少写了一个测试，或者是程序中有多余的代码。类似的，针对任何一个逻辑表达 式，是否可以将它取反？哪些测试会通不过？如果没有测试通不过的话，那么你显然需要再写一些测试，或者清除一些代码。

　　比尔：听起来似乎可以将这个过程自动化。

　　马丁：事实上，有专门的程序做这个，叫 JesTer。问题是，它运行所需要的时间太长了。它每做一个小改动，就要把整个测试都重新生成一遍。