TDD的实施细节应该怎样做

0 0

TDD的实施细节应该怎样做10

哈哈，标题党了。其实是我求细节操作。
以前也有看过一些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了。

仅供参考。

1.unit test和功能测试肯定是不一样的。我问的是xp和tdd需不需要写需求规格说明书。
2.我要说的是TDD，不是DDD.你的意思是不是先DDD完了，再进入TDD?
3.但我好像看以前某些牛说TDD中的Test Driver不是unit test driver,而是需求test driver.当然如果要tdd,unit test肯定是必需的了，测试-->重构-->设计，然后反复。
4.这个基本上同意。
5.成员水平不一样可以采取结对方式提升人员水平，对于你这个观点，我不同意。我记得几年前，有人讨论过水平不一样，结对更加容易流产。

问题补充：<div class="quote_title">gigix 写道</div><div class="quote_div"><div class="quote_title">peterwei 写道</div><div class="quote_div">5.成员水平不一样可以采取结对方式提升人员水平，对于你这个观点，我不同意。我记得几年前，有人讨论过水平不一样，结对更加容易流产。</div> <br /><div class="quote_title">peterwei 写道</div><div class="quote_div">我的观点是一个经验丰富的带一两个新手共同开发一个模块，但并不需要结对的方式。 </div> <br />你明明没做过，哪儿来的这么多观点呢？</div> <br />是不是一定要亲自做过，才能有这个观点呢？我们权且不论这个观点是对还是错。这只是我的一个想法，而且也是经过实践的，只不过不是结对的方式。另外我也非常希望你能给我一些TDD细节方面的见议。再问一下，你觉得老抛的观点怎么样？ <br />

问题补充：<div class="quote_title">humaeks 写道</div><div class="quote_div">1. tdd是编程技巧和风格，与规格说明书不是同一级别的东西，那个应该是scrum或者整个agile development所关注的； <br />2. tdd是编程技巧，DDD是设计方式，按软件生命周期，需求、设计（大设计）、编码、测试，每个小迭代里面还是按这个走的，至少在我当前的开发流程里面是这样，可能我对这个的理解不深； <br />3. 需求test driven是对的，关键看需求如何拆分，是逻辑代码段的需求，还是系统功能需求。抽象一点来说，tdd背后是一种风格，指在所有事情开始之前，先考虑验收，实际上很老的软件工程理论就说了测试应该在需求阶段就介入，并根据需求规格编写对应的验收测试。TDD只是把这种风格带到coding环节； <br />4. <br />5. mentoring很累，很容易流产，所以必须看苗子，另外就是个人魅力和忽悠。 <br /> <br />继续，个人愚见而已。</div> <br />看来我们的想法已经统一了。就是不知道对不对。

TDD 敏捷编程

2011年1月13日 10:14

peterwei
107
0 0 0

6个答案按时间排序按投票排序

0 0

采纳的答案

TDD是手法
Scrum是管理
现在我对Scrum还是没办法全作.

TDD很简单.
1.不启动tomcat测试
2.不启动DB写逻辑
3.所有的程序员必须可以口述所写的东西.
4.每个逻辑只写在一个类里不需要页面配合.
5.非hibernate的话可以连数据库写DAO
6.真实的对应自己的需要.而不是什么套路.
7.每个会出错的文件对应一个测试,

每次出现了错误你会点测试,那个按钮.改成你想要的样子,你要是能顺利改成可以过了的程序会有一种爽快感,有了test的限制后,就了有种没有限制的世界,如果你还能发现更理性的代码写法.会更爽快.
上了正轨之后几乎没有人会退回去

结对只要你的公司能支付的起工资
你的工作不是拷贝代码
效果非常不错.
当然楼上说的人品是个问题.但我遇到不能结对的人只占很少的一部分

DDD需要更多的上层支持更.
很有可能技术不是问题.
人是很关键的
如果压力很大的话不建议进行这种尝试

其它的一些设计,需求,计划的一些实践很困难......没有成功过

2011年1月13日 10:14

抛出异常的爱
619
0 0 5

添加评论

0 0

稍稍再补充一点，所有的这些都是方法论。研究方法论的方式就是实践，实践的时候能把握住方法论的constraint和它能产生benefit的原因，然后根据本身团队情况来进行调整。千万不要想着一步到位。

2011年1月13日 14:50

humaeks
147
0 0 0

添加评论

0 0

1. tdd是编程技巧和风格，与规格说明书不是同一级别的东西，那个应该是scrum或者整个agile development所关注的；
2. tdd是编程技巧，DDD是设计方式，按软件生命周期，需求、设计（大设计）、编码、测试，每个小迭代里面还是按这个走的，至少在我当前的开发流程里面是这样，可能我对这个的理解不深；
3. 需求test driven是对的，关键看需求如何拆分，是逻辑代码段的需求，还是系统功能需求。抽象一点来说，tdd背后是一种风格，指在所有事情开始之前，先考虑验收，实际上很老的软件工程理论就说了测试应该在需求阶段就介入，并根据需求规格编写对应的验收测试。TDD只是把这种风格带到coding环节；
4.
5. mentoring很累，很容易流产，所以必须看苗子，另外就是个人魅力和忽悠。

继续，个人愚见而已。

2011年1月13日 14:33

humaeks
147
0 0 0