万事开头难。在TDD中，人们纠结最多的可能是这样一个问题：如何写第一个测试呢？实际上要视不同的问题而定。如果问题本身是一个算法求解，或者是一个大系统中的小单元，那么可以从最简单、最直观的情况出发，这样有助于快速建立信心，形成反馈周期。但是在实际的开发中，很多时候我们拿到的就是一个“应用级”的需求：一个网上订票系统，一个网上书店，愤怒的小鸟，诸如此类。此时，我们如何TDD呢？一种很自然的想法是：
先对系统做简单的功能分解，形成概念中的相互协作的小模块。然后再从其中的一个小模块开始（往往是最核心的业务模块）TDD。我们把这种方式权且称为inside-out，也就是从部分到整体。这种方式可能存在的风险是：即使各个部分都通过TDD的方式驱动出来，我们也不能保证它们一起协作就能是我们想要的那个整体。更糟糕的是，直到我们把各个部分完成之前，我们都不知道这种无法形成整体的风险有多大。因此这对我们那个“概念中模块设计”提出了很高的要求，并且无论我们当前在实现哪个模块，都必须保证那个模块是要符合概念中的设计的。
如果换一种思路呢？与其做概念中的设计，不如做真正的设计，通过写测试的方式驱动出系统的各个主要模块及其交互关系，当测试完成并通过，整个应用的“骨架”也就形成了。
例如，现在假设我们拿到一个需求，要实现一个猜数字的游戏。游戏的规则很简单，游戏开始后随机产生4位不相同的数字（0－9），玩家在6次之内猜出这个4位数就算赢，否则就算输。每次玩家猜一个4位数，游戏都会告诉玩家这个4位数与正确结果的匹配情况，以xAyB的形式输出，其中x表示数字在结果中出现，并且出现的位置也正确，y表示数字在结果中出现但位置不正确。如果玩家猜出了正确的结果，游戏结束并输出“You win”，如果玩家输，游戏结束并输出“You lose”。
针对这样一个小游戏，有人觉得简单，有人觉得复杂，但无论如何我们都没有办法一眼就看到整个问题的解决方案。因此我们需要理解需求，分析系统的功能：这里需要一个输入模块，那里需要一个随机数产生模块，停！既然已经在做分析了，为什么不用测试来记录这一过程呢？当测试完成的时候，我们的分析过程也就完成了。
好吧，从何开始呢？TDD有一个很重要的原则－反馈周期，反馈周期不能太长，这样才能合理的控制整个TDD的节奏。因此我们不妨站在玩家的角度，从最简单的游戏过程开始吧。
最简单的游戏过程是什么呢？游戏产生4位数，玩家一把猜中，You win，游戏结束。
现在开始写这个测试吧。有一个游戏（Game），游戏开始（start）：
Game game =newGame(); game.start(); |
等等，似乎少了什么，是的，为了产生随机数，需要有一个AnswerGenerator；为了拿到用户输入，需要有一个InputCollector；为了对玩家的输入进行判断，需要有一个Guesser；为了输出结果，需要有一个OutputPrinter。真的要一口气创建这么多类，并一一实现它们吗？还好有mock，它可以帮助我们快速的创建一些假的对象。这里我们使用JMock2：
| Mockery context = new JUnit4Mockery() { { setImposteriser(ClassImposteriser.INSTANCE); } }; final AnswerGenerator answerGenerator = context.mock(AnswerGenerator.class); |
然后我们测试里的Game就变成这个样子了：
Game game =newGame(answerGenerator, inputCollector, guesser, outputPrinter); game.start(); |
注意到这里为了通过编译，需要定义上面提到的几个类，我们不妨以最快的方式给出空实现吧：
public class AnswerGenerator { public class InputCollector { public class Guesser { public class OutputPrinter { |
以及为了通过编译而需要的Game的最简单版本：
| public class Game { public Game(AnswerGenerator generator, InputCollector inputCollector, Guesser guesser, OutputPrinter outputPrinter) { } public void start() { } } |
