测试驱动开发

        到现在项目进行了接近50%了.
        项目编码到中途时,项目负责人对我们提出意见,测试优于代码开发.
        在代码开发中,对我感触最大的是,在代码进行中,由于自己对自己开发模块的设计不足,导致开发途中对项目实现的多次修改,由于项目功能实现考虑不够周全,对代码频繁改动,对数据迁移文件频繁改动,虽然rails对数据库的变更很方便,但是仍然浪费了不少时间,降低了效率.
        如果采取测试优先的方式,我想最大的好处莫过于,对于模块是一个从模块接口和功能实现入手,再细分代码的实现.这样做会是开发,有一个由功能到实现,由概括到细节的过程,从而再一定程度上减少返工,提高效率.
        不过,测试驱动开发,是需要测试要有很高的质量,而且,对于项目经验不足,可能会导致不知道如何下手去写.
        作为一个开发人员,大家都知道,往往修改代码和调试的时间占据了代码开发的大部分时间,所以测试写的好,可以很好的进行控制代码修改和调试,而不用担心会过于注重细节的实现忽略代码的功能.
        rails的consol和ruby的irb是很不错的调试工具,用的好,对于查找错误,修改错误很有帮助.

   

 

评论

31 楼 orcl_zhang 2010-01-17  

chenjianjx 写道

我不喜欢先写测试再写代码，因为它 "against human nature"，因为大多数程序都是先有设计思路后，才会想到测试，毕竟设计更好玩嘛。

先写设计测试用例可以使你的开发做得更完备，因为你这时还没写正式代码，不会被正式代码先入为主地影响你的测试用例。

但是，如果先写设计用例的话，真的很不快乐，还是顺自己的本心比较好。

彼此，先写测试用例，再写代码，我也适应不了，感觉无从下手。
不过没有尝试过，以后希望自己能在实际开发中能体验下，或许能得到意外的收获。

30 楼 chenjianjx 2010-01-12  

我不喜欢先写测试再写代码，因为它 "against human nature"，因为大多数程序都是先有设计思路后，才会想到测试，毕竟设计更好玩嘛。

先写设计测试用例可以使你的开发做得更完备，因为你这时还没写正式代码，不会被正式代码先入为主地影响你的测试用例。

但是，如果先写设计用例的话，真的很不快乐，还是顺自己的本心比较好。

29 楼 xwk19831010 2010-01-12  

测试驱动开发 属于 敏捷软件开发范畴， TDD之前准备大量的文档不是敏捷所推荐的！~terryh 确实没弄明白！

28 楼 shatuo 2009-12-01  

mock1234 写道

不知道如何写测试这是很常见的问题。

但是其实也不算什么问题，你刚入行的时候不是也不知道如何写出代码吗？

其实先写测试是一个过程问题，或者是一个态度问题，而不是一个技术问题。

不要把调试跟TDD搞混了。TDD是一种设计手段，而单元测试以及调试都是事后对代码说三道四，而不是事前设计。

单元测试不是在编码前就开始做了吗？只要不是劳动密集型的行业，先完成单元测试用例设计可能会更容易控制，跑过测试，成功一半了。

27 楼 pioneer21th 2009-11-30  

我觉得TDD的思想对我贡献最大的是在写代码时就考虑怎么写UT才能简单些。
不好写UT的代码质量肯定也是不好的，我认同。

26 楼 whaosoft 2009-11-30  

mock1234 写道

不知道如何写测试这是很常见的问题。

但是其实也不算什么问题，你刚入行的时候不是也不知道如何写出代码吗？

其实先写测试是一个过程问题，或者是一个态度问题，而不是一个技术问题。

不要把调试跟TDD搞混了。TDD是一种设计手段，而单元测试以及调试都是事后对代码说三道四，而不是事前设计。

mock1234这点说的很对~ "不要把调试跟TDD搞混了。TDD是一种设计手段，而单元测试以及调试都是事后对代码说三道四，而不是事前设计。"

25 楼 star022 2009-11-30  

terryh 写道

daquan198163 写道

楼上说的流程是TDD吗？

对不起，我还没开始了解TDD。以后有时间要补一下TDD的知识。
我说的是从我经历的项目总结的观点，纯属个人看法。希望和大家交流一下。

你这么一说，着实把我雷倒了！ ~~~ :lol

24 楼 star022 2009-11-30  

gigix 写道

terryh 写道

测试驱动开发是建立在详细的文档之上的。所以对于没有时间认真写文档的项目不推荐测试驱动。

这狗屁论点的论据又在哪里嘛，说出来大家学习一下嘛。

用列本身就可以作为一份维护文档，要制定良好的用列注释规范。

23 楼 daquan198163 2009-11-30  

terryh 写道

gigix 写道

Kent Beck说，

写测试=>红=>写代码=>绿=>重构=>绿

就这么简单

先看书再讨论吧。你说那套V模型其实也挺好的，只不过做业务流程测试的时候多加点班而已。

明白你的意思。
我的意思是 写测试的前提是要有详细的文档。这样才能摘出具体的功能点。
我们的流程到编码阶段前期基本上项目就很清楚了。
所以从编码开始问题都已经很量化，不需要加班。很轻松。真是这样的。

详细到什么程度，你说的是详细设计么？
详细设计文档有个大问题——难以维护，很快就会变得与代码不一致，最后被丢弃
并且详细设计会使程序员倾向于按照既有设计完成工作，而不是根据实际情况优化设计。

22 楼 hongkong 2009-11-30  

佛日：不能为了禅而禅

个人觉得：这么多开发方式，目的都在于驱动出良好的设计。
详细的需求设计文档也是一种手段，问题在于，你一开始很难抓住需求的本质
随着编码的进行，我们会越来越抓住需求的本质，因此需要重构（DDD讲的就是这么一码事），不光代码需要重构，模型也需要。
TDD最大的好处，在于将需求和测试（不是测试人员的测试）结合起来，配合重构技术，理解需求的本质，驱动出良好的设计
一个表现就是抽象，先写出你要的抽象，然后实现它，妙处难于言传，哈哈

21 楼 fansofjava 2009-11-29  

terryh 写道

gigix 写道

Kent Beck说，

写测试=>红=>写代码=>绿=>重构=>绿

就这么简单

先看书再讨论吧。你说那套V模型其实也挺好的，只不过做业务流程测试的时候多加点班而已。

明白你的意思。
我的意思是 写测试的前提是要有详细的文档。这样才能摘出具体的功能点。
我们的流程到编码阶段前期基本上项目就很清楚了。
所以从编码开始问题都已经很量化，不需要加班。很轻松。真是这样的。

先了解以后再说吧，你肯定是没理解TDD的。

20 楼 orcl_zhang 2009-11-29  

gigix 写道

去 www.douban.com ，在搜索框输入“测试驱动开发”，选Kent Beck写的那本，买回家，看
既然知道自己没看过这方面具体的书，是不是应该至少先看了再来讨论？

有时间看看.

19 楼 terryh 2009-11-29  

提示：选择您需要装饰的文字, 按上列按钮即可添加上相应的标签

18 楼 terryh 2009-11-29  

提示：选择您需要装饰的文字, 按上列按钮即可添加上相应的标签

17 楼 gigix 2009-11-29  

Kent Beck说，

写测试=>红=>写代码=>绿=>重构=>绿

就这么简单

先看书再讨论吧。你说那套V模型其实也挺好的，只不过做业务流程测试的时候多加点班而已。

16 楼 terryh 2009-11-29  

提示：选择您需要装饰的文字, 按上列按钮即可添加上相应的标签

15 楼 terryh 2009-11-29  

提示：选择您需要装饰的文字, 按上列按钮即可添加上相应的标签

14 楼 gigix 2009-11-29  

terryh 写道

gigix 写道

去 www.douban.com ，在搜索框输入“测试驱动开发”，选Kent Beck写的那本，买回家，看
既然知道自己没看过这方面具体的书，是不是应该至少先看了再来讨论？

请直接回答我的问题，谢谢！

我回答还不就是跟Kent Beck说的一样

关于TDD是什么
要么你说的跟Kent Beck一样，那么你是在说废话
要么你说的跟他不一样，那么你说错了

既然如此，出于什么必要再说下去？

当然如果你付钱的话我可以考虑把Kent Beck的话再复述一遍甚至复述很多遍直到你听懂
不过现在我是没看出来为什么我应该直接回答你的问题。所以，不用谢。

13 楼 terryh 2009-11-29  

提示：选择您需要装饰的文字, 按上列按钮即可添加上相应的标签

12 楼 gigix 2009-11-29  

去 www.douban.com ，在搜索框输入“测试驱动开发”，选Kent Beck写的那本，买回家，看
既然知道自己没看过这方面具体的书，是不是应该至少先看了再来讨论？