TDD是否有效，是否能够驱动设计，我在此不想给出答案，以避免陷入业界多年以来对于TDD的争纷。事实上，武断地说TDD好，或是不好，都是不负责任的做法。因此，在这里，我只想来谈谈自己对TDD一些思考。

　　让我们先来看看TDD的过程，如下图所示：

　　TDD的过程是一个从输入到输出的过程。输入就是寻找任务、编写适当的测试用例，最终的输出则是合理设计的实现代码。如此，即可将TDD的过程转换为：

　　1）如何寻找正确的任务列表？

　　2）如何编写好的测试用例？

　　3）何谓简单设计？

　　4）如何发现代码的坏味道？

　　5）如何重构？

　　以上五个环节正是TDD的关键。如果说这个过程蕴含着“驱动”的涵义，这正是一种驱动设计的过程。我们必须要将每一个环节都做好，TDD才能变得有效；否则一切都只是镜花水月。这正是TDD的困难之处，也是它的争议之处，对于我而言，却也正是TDD的迷人之处。

　　一、如何寻找正确的任务列表

　　通常而言，实施TDD的团队都会从用户故事（User Story）开始分析需求，辨别我们将要完成的任务（功能）列表。典型的用户故事事实上描写了一个场景，通过诸如：As， I would like， So that……这样的句式展开对场景的描述。这种描述方式分别包含了角色、功能、业务价值三部分内容。

　　在职责驱动设计中，我们常常将角色作为场景分析的入口点，通过角色所要执行的功能，来识别对象以及对象的职责，并合理地分配对象的职责，实现良好的对象协作。TDD的方式与之相似。这是因为好的测试项事实上应该是一种规格说明，是对业务场景的一种模拟，是站在调用者（测试者）的角度去揣摩对象或接口的意图，而非考虑具体的实现。当我们在分析User Story时，就可以从角色的角度分析这个需求所需要完成的任务。每个任务可能代表一个功能或者职责，组合起来正好能够为完整的场景服务。例如这样的一个User Story：

　　view sourceprint？As an Account Administrator
　　I would like the bank to track new customers
　　So that we can tie all records of them together

　　对于这样的一个用户故事，从Account Administrator的角色出发，所能获得的一个场景就是：创建一个客户对象，然后将新建的客户对象添加到银行的账户系统中。于是，根据场景，我们能够辨识出两个任务：

　　1）创建一个新的客户；

　　2）添加一个创建好的客户；

　　在整个用户故事中，虽然我们将其分割为两个任务，但这两个任务始终是为一个业务价值服务的。一个好的用户故事应该遵循INVEST模式（Independent， Negotiable， Valuable， Estimable， Small， Testable），因此在分析任务时，需要分析这些任务是否是为同一个业务目标服务。如果发现任务繁多，体现为多个业务价值，就应该思考这个用户故事的划分是否合理。所以在TDD的过程中，对于输入部分的用户故事而言，是需要思考和分析的，一方面是为了从角色的角度入手，获得我们可以分解的任务列表，另一方面也可以反过来判断用户故事的编写与划分是否合理。

　　当然，在一个典型的用户故事中，都会给出一些验收条件（Acceptance Criteria），这些验收条件既可以转换为任务，也可以视为实现功能或职责的一种约束。例如这样的验收条件：

　　view sourceprint？1.Each customer has a nickname？
　　2.Valid nickname contain only lowercase letters or digits
　　3.Each customer has a dateOfBirth？（DateTime）
　　4.Customers may be added to the Bank provided that there is not an existing customer with the same nickname？

　　在这些验收条件中，前面三个验收条件可以看做是第一个任务的约束，后一个验收条件则是第二个任务的约束。对于验收条件而言，既可以作为验收测试的一种输入，又是TDD测试用例的一个重要参考。有了任务和验收条件作为基础，我们就能够比较容易地编写合乎需要的测试用例了。