测试驱动和用例驱动的联合实践

用例驱动方法来自UP，由jacobson提出，并成为UP中最闪亮的瑰宝和核心,用例驱动主张一切来自需求，这本身非常正确，但用例之后的分析，设计过程被一些敏捷专家所诟病，认为这个过程太过重量级，因为需求一直在变，而且随着项目的进展，设计会弱化，同时还得保持分析文档，设计文档和代码的同步，如果能时刻保持增量和迭代那么还好，否则就是灾难了。

测试驱动则采取另外的思路，非常轻型的分析和设计，所有的代码从测试的角度产生，一旦需求发生改动，重构代码到测试通过。传统上，大多数人是先写代码再写测试，如果已知代码可行，确实写测试也会失去激情，随着项目的深入，需求的改动，最后期限的到来，为代码编写测试就是mission impossible。

那么两种非常优秀的开发方法如何结合呢？
我来谈谈我的一点初步的实践:
实践中我发现用例驱动和测试驱动有重叠的地方，因为在测试驱动的前期会有很多称之为story的东西，我认为这个story就是需求( 测试驱动偏重于代码的编写和维护，对story介绍相对较少) ,既然是需求,还有什么比使用usecase更贴切的呢,我在项目中通常首先使用usecase做需求,这样会对整个项目有个全局的认识,然后我再根据usecase做测试驱动(此前还会做些简单的领域分析) ,实际上我们将测试驱动很大程度上取代了up需求之后的分析,设计和编码,一旦需求发生改动,我会考虑更新usecase(可跟踪被建模的代码),然后改写测试,改写代码(几乎100%要重构代码),最后进行单元测试来保证我的改动没有破坏我所有预期的行为.

这样做的好处在于:
1) 采用usecase可以很好的反应需求,同时也可以很平滑的过渡到代码,是一个跟踪需求和代码的很好的手段
当然这牵涉到如何编写有效用例的问题,这超出了本文讨论的范围,请参考其他文献
2)采用测试驱动可以大胆的重构代码和不必担心引入bug,而且所有的代码都来自于测试,这就使得代码可控.另外测试可以改进设计,通常不方便测试的代码往往耦合严重,等你改动代码方便测试了,往往你的设计会变得更好.
当然这里面还牵涉到如何测试和测试覆盖率的统计问题,这超出了本文讨论的范围,请参考其他文献