qinker
qinker
2011-01-13 10:14

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了。

仅供参考。

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

6条回答

  • m_m1m2m3m4m5 m_m1m2m3m4m5 10年前

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

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

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

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

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

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

    点赞 评论 复制链接分享
  • humaeks humaeks 10年前

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

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

    继续,个人愚见而已。

    点赞 评论 复制链接分享
  • iteye_17757 iteye_17757 10年前

    tdd,中文翻成测试驱动的设计或开发,取决于最后一个d,因此要理解测试驱动,由测试产生设计或实现

    点赞 评论 复制链接分享
  • humaeks humaeks 10年前

    个人的几点愚见,有点零乱:

    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了。

    仅供参考。

    点赞 评论 复制链接分享
  • java_editor java_editor 10年前

    [quote="peterwei"]5.成员水平不一样可以采取结对方式提升人员水平,对于你这个观点,我不同意。我记得几年前,有人讨论过水平不一样,结对更加容易流产。[/quote]
    [quote="peterwei"]我的观点是一个经验丰富的带一两个新手共同开发一个模块,但并不需要结对的方式。 [/quote]
    你明明没做过,哪儿来的这么多观点呢?

    点赞 评论 复制链接分享

相关推荐