问题描述
哈哈，标题党了。其实是我求细节操作。以前也有看过一些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 写道
解决方案
TDD是手法Scrum是管理现在我对Scrum还是没办法全作.TDD很简单.1.不启动tomcat测试2.不启动DB写逻辑3.所有的程序员必须可以口述所写的东西.4.每个逻辑只写在一个类里不需要页面配合.5.非hibernate的话可以连数据库写DAO6.真实的对应自己的需要.而不是什么套路.7.每个会出错的文件对应一个测试,每次出现了错误你会点测试,那个按钮.改成你想要的样子,你要是能顺利改成可以过了的程序会有一种爽快感,有了test的限制后,就了有种没有限制的世界,如果你还能发现更理性的代码写法.会更爽快.上了正轨之后几乎没有人会退回去结对只要你的公司能支付的起工资你的工作不是拷贝代码效果非常不错.当然楼上说的人品是个问题.但我遇到不能结对的人只占很少的一部分DDD需要更多的上层支持更.很有可能技术不是问题.人是很关键的如果压力很大的话不建议进行这种尝试其它的一些设计,需求,计划的一些实践很困难......没有成功过
解决方案二：
稍稍再补充一点，所有的这些都是方法论。研究方法论的方式就是实践，实践的时候能把握住方法论的constraint和它能产生benefit的原因，然后根据本身团队情况来进行调整。千万不要想着一步到位。
解决方案三：
1. tdd是编程技巧和风格，与规格说明书不是同一级别的东西，那个应该是scrum或者整个agile development所关注的；2. tdd是编程技巧，DDD是设计方式，按软件生命周期，需求、设计（大设计）、编码、测试，每个小迭代里面还是按这个走的，至少在我当前的开发流程里面是这样，可能我对这个的理解不深；3. 需求test driven是对的，关键看需求如何拆分，是逻辑代码段的需求，还是系统功能需求。抽象一点来说，tdd背后是一种风格，指在所有事情开始之前，先考虑验收，实际上很老的软件工程理论就说了测试应该在需求阶段就介入，并根据需求规格编写对应的验收测试。TDD只是把这种风格带到coding环节；4.5. mentoring很累，很容易流产，所以必须看苗子，另外就是个人魅力和忽悠。继续，个人愚见而已。
解决方案四：
tdd,中文翻成测试驱动的设计或开发，取决于最后一个d，因此要理解测试驱动，由测试产生设计或实现
解决方案五：
peterwei 写道5.成员水平不一样可以采取结对方式提升人员水平，对于你这个观点，我不同意。我记得几年前，有人讨论过水平不一样，结对更加容易流产。peterwei 写道我的观点是一个经验丰富的带一两个新手共同开发一个模块，但并不需要结对的方式。 你明明没做过，哪儿来的这么多观点呢？
解决方案六：
个人的几点愚见，有点零乱：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了。仅供参考。