TDD的粒度

一般来讲，TDD的开发方式由三个步骤组成：
1. 编写一个失败的测试用例
2. 编写功能代码让这个测试通过
3. 如果代码有坏味道，就Refactor，否则goto 1

但是实际开发中，在哪一个层面上编写这个失败的用例是一个更为关键的问题。比如说一个Invitation的需求，我们可以

1. 用Selenium编写一个Acceptance Test，
2. 对Controller 开始编写一个Functional Test
3. 编写一个ActionMailer Test.
4. Invitation Model的 Unit Tests

选择哪一个测试好呢？显然这4个测试的粒度是依次递减的。我习惯于从最小粒度的Test开始编写，因为这样我能够保证每次都以最快速度来通过测试，步入下一个迭代。

这里有一个疑问，大粒度的Test往往能够覆盖细粒度Test所描述的行为，那么细粒度Test是否是一种增加开发成本的冗余？显然不是。一个Model里面的Bug在Functional Test里面发现和Unit Tests里面发现成本是不一样的。

从最小粒度的Test开始并不是容易的事情，因为当我从一个失败的Test中的反馈才知道通过这个Test还要从更底层开始实现，那么这个Test的粒度很有可能过大了。我的做法是注释掉这个Test，在底层编写更细粒度的Test，通过以后回过头来处理这个测试。有很强的Prefactoring能力也许会降低这种探索的成本，不过对于我这种智商，还是从最小粒度的测试开始比较好。