TDD测试驱动开发︱一个完整的TDD测试驱动开发演练案例

旦分析清楚，就应该编写测试，通过测试来驱动对象之间的协作方式。在编写的测试中，参与协作的其他对象都可以通过Mock来模拟，不一定要有实现，只需体现它们的接口即可。

 

例如，在当前这个测试中，除了之前已经处理过的Game与AnswerGenerator之间的协作外，我主要考虑了InputCommand与GameView之间的协作方式，其中包括：三者之间的依赖注入，例如GameView作为构造函数的参数，因为一个GameController对象应对应一个GameView对象；而InputCommand则作为play()方法的输入参数。这里的GameController的接口就是通过测试驱动获得的。由于我们测试的是历史猜测结果是否显示，因此使用了Mockito框架的verify方法对这种对象之间的协作进行了验证。之所以在验证逻辑中没有验证具体的猜测结果是否正确，是因为这个逻辑已经在Game的测试中覆盖；而对于GameController，我们需要验证的逻辑只限于“是否显示历史猜测数据”，而非“显示了什么样的历史猜测数据”。

 

注意：这里创建了多个Mock对象，因此使用了Mockito提供的@Mock便捷方式来创建这些Mock对象。

 

InputCommand可以定义为接口，真正的控制台实现交给了ConsoleInputCommand类。实现如下：

 

 

测试驱动开发完整案例的最后一部分，除完成了整个案例的测试驱动之外，还介绍了依赖注入以及测试驱动开发的定律与原则。

 

开始第五个任务

 

在开始编写测试之前，先要深入分析该任务表达的需求信息。“判断游戏结果。判断猜测次数，如果满6次但是未猜对则判负；如果在6次内猜测的4个数字值与位置都正确，则判胜。”实际上这里引入了对游戏猜测的控制逻辑，主要是对猜测次数的控制。这样的控制逻辑应该交给谁呢？

 

多数时候，程序员容易将这样的控制逻辑放到主程序入口处，即main()函数中。这并非恰当的方式。一方面，这里的控制逻辑仍然属于业务逻辑的范畴，不应该暴露给调用者，同时也加大了调用者的负担；另一方面，倘若程序不再作为控制台程序时，例如编写Web Application，主程序入口的内容就要调整，甚至导致这一逻辑的重复。

 

有了编写第四个任务作为基础，我们很容易判断出该控制逻辑应该交给GameController。编写测试也变得简单：

 

 

这里的两个测试与第四个任务测试“显示历史猜测数据”任务的测试相似，唯一不同的是我们添加了对InputCommand协作的验证，并以Mockito提供的times()方法准确的验证了调用的次数。默认情况下，verify验证的次数为1，但我在第一个测试中仍然给出了times(1)，是希望在测试中明确的表示它被执行了一次。

 

通过编写测试，我们驱动出了GameController、InputCommand与GameView之间的协作关系，并且还驱动出showMessage()方法。如果你觉得showMessage()方法的定义太过宽泛，也可以定义showFailure()和showSuccess()方法来体现这里表达的业务逻辑。

 

GameController的实现就变简单了：

 

 

运用依赖注入框架

 

至此，我们的程序基本完成。我们定义并实现了各个参与协作的类，但是，我们需要管理类之间的依赖，组合这些相关的对象。由于我们采用了测试驱动，因此比较好的保证了各个类的可测试性，而达成可测试性的诀窍就是“依赖注入”。

 

知识：依赖注入

 

依赖注入模式体现了“面向接口设计”原则，即分离接口与实现，并通过构造函数注入、设值方法注入或接口注入等手法将外部依赖注入到一个类中，从而解除该