关于TDD

我们已经看到了太多的TDD例子， 无非是一些计算器，Stack,保龄球游戏， 拍卖物品等等。 它们都太简单了，只能拿来吸引眼球，展示一些基本的TDD概念。

每个人都很容易理解TDD的基本步骤：

• 编写一个失败的测试
• 开发足够的代码让测试通过
• 重构

但是为什么我们不能把它们应用到自己的实际开发工作中去？ 为什么我们想利用TDD进行新需求开发的时候还是手足无措，不知道如何下手？

敏捷实践中的TDD只是告诉了我们形式 ，没有告诉我们内容 ， 更重要的是对于不同类型的应用程序 它没有告诉我们如何开始 ！

 

首先需要澄清一个问题，TDD只是针对单元测试吗？我想答案是否定的。 因为当我们接到需求的时候，还没有任何代码存在，我们没有办法直接跳到Class Level去写测试，只能先针对某些场景，功能，行为编写一些测试， 试图从客户的角度来观察，使用系统。  这样的测试当然不是单元测试， 我们可以称之为场景或验收测试。

可能有人问了，需求太大怎么办？难道你的测试的粒度很粗吗？那样还有什么意义? 
 答案是对需求进行“垂直”的"切片", 让每一片都足够小，但是有足够完整， 例如对Web application ,每个切片都应该包括UI Layer, Business Logic Layer, Database Layer.   把需求进行有效的”切片“是敏捷开发中一个关键的技能， 开发人员必须要学会把一个需求切成一个个可以循序渐进开发的小片， 每个切片都是自己的一个ToDo的 List.

 

OK, 现在验收测试有了，接下来呢？ 怎么让它pass ? 
当然是写代码了:-)    注意： 开始的时候一些Class 并没有单元测试保证 ，它们可能非常的直接，非常的简单 我们脑海中可能一下子就会浮现出来， 但是对于另外一些类，你可能只清楚它的接口， 不清楚怎么样去完成具体的功能， 我们熟悉的Class Level级的TDD 需要进场了！ 

需要注意的是尽可能用简单的代码来完成功能， 让验收测试通过。 在对别的“切片”进行开发的时候，那些简单的，直接的Class可能会变得复杂，僵化，有了Bad Smell, 重构再所难免， Class Level的TDD 仍然会大展身手。

 

总结一下：
(1)  不是所有的东西都是TDD出来的
（2） TDD至少会被用到两个测试级别上：验收测试和单元测试  ， 两者相辅相成，共同作用，完成一个”需求切片“开发的TDD 循环。