TDD的实施细节应该怎样做

　　以前也有看过一些TDD的资料，但一直没有在实际的项目中实践过。最近可能有一个新的项目，不是特别大，想采用Scrum和TDD小试身手。先介绍一下我们以前项目的开发流程：

　　1.拿下项目，需求调研分析，编写需求用例(如果客户没有要求，需求规格说明书都不写)

　　基本上需求用例就是说明什么人，做什么事情，怎么做，达到什么目的，有什么要求这些。

　　2.然后分析领域对象，分析业务流程和场景。并最终生成数据库物理模型。

　　3.概要设计，其实也没什么，就是数据库结构，还有用例描述加一些时序图。

　　4.根据需求用例，编写测试用例。

　　5.开发人员进行开发，有时项目紧的时候，单元测试都不写(这个项目没有明文要求)，主要靠开发人员个人意愿。

　　6.根据周期定期进行打包测试。我一般会每周build两次，亲自操作一下业务流程，有问题提出修改。这个过程测试人员未参与。

　　7.测试人员进入，按模块完成的先后顺序，持续的测试修改。

　　以前的项目基本上是采用领域驱动的方式进行一步步开发的。现在打算采用TDD方式，现有一些细节疑问，打算请教一下实施了TDD的各种牛。

　　1.TDD方式是不是不用写需求说明书了?

　　2.分析领域对象，分析业务流程和场景。并最终生成数据库物理模型。这一步是不是在TDD之前完成?

　　3.不写概要设计，由需求用例直接跳入TDD开发?

　　4.测试用例是不是需求用例的细化和规范?

　　5.TDD中的test是基于单元测试，还是基于需求测试?

　　6.如果是单元测试，自然由开发人员完成。如果TDD是基于需求测试，那么开发人员是否需要测试人员配合?

　　最后一个问题是：大家有结对编程的习惯吗?在实践过程中结对是否高效?反正我是觉得结对不会太高效的，主要是基于项目人员的配置本来就有成本在那里，而且人员水平也不一样。我的观点是一个经验丰富的带一两个新手共同开发一个模块，但并不需要结对的方式。

　　ok,问题完了。等大家拍砖。

　　问题补充

　　humaeks 写道

　　个人的几点愚见，有点零乱：

　　1. 首先明确unit test和功能测试不一样，参与的人也不一样。

　　2. 设计完了再入TDD阶段，写UT的过程其实也是校验测试的过程，如果测试不好写，就需要review设计。这里插播一下，既然考虑采用DDD，应该先出来CDM，然后java OO与CDM对应，剩下才是设计物理模型和持久层

　　3. 传统意义上的TDD指的是unit test。背后很重要的一个思想是先写测试有助于写出clean code that works, 或者说是just enough的代码，实践上需要权衡。对程序员的编程技巧要求高，在我的团队成员中，从零到真的能写出“单元”测试，需要每天抽一小时1 on 1 code review一个月以上。

　　需要程序员有逻辑拆分以及一些coding技巧，看implementation patterns / clean code 这两本书会有帮助，但关键还是每天的code review给及时反馈。

　　4. 100%覆盖是不切实际的东西，尤其是初次尝试TDD，可以采用以点带面的方式，让部分成员先尝试到TDD带来的好处，然后在团队中传播;

　　5. 成员水平不一样可以采取结对方式提升人员水平，但成本回收周期长，基本不会对本项目(3月内的项目)产生benefit，但遇到有好苗子要坚决培养，否则日后还是会死，留不留得住人，就是另外一个管理topic了。

原文转自：http://www.ltesting.net