Are you doing Test-Driven-Development(TDD)

ybbest

Not sure how many people doing TDD at work as programmer.
Here is the link for the benefits of it.
http://googletesting.blogspot.com/2009/07/by-shyam-seshadri-nowadays-when-i-talk.html

[ 本帖最后由 ybbest 于 2009-7-25 15:33 编辑 ]

ybbest

More links to in
http://www.bugfree.dk/blog/2009/ ... testing-guidelines/

ybbest

[ 本帖最后由 ybbest 于 2009-7-24 11:49 编辑 ]

leiz

是TDD不是DTT
很好的感念,在开发新的feature的时候很适用,但是如果现有的code没有unit test,实施起来太过麻烦

ybbest

原帖由 leiz 于 2009-7-25 14:31 发表
是TDD不是DTT
很好的感念,在开发新的feature的时候很适用,但是如果现有的code没有unit test,实施起来太过麻烦

是。。。。。。。。。。。。。。。。。

John.G

TDD不错。。。是预防Bug的最佳方法

newmike

如果时间充裕，TDD挺好，其实只要真肯花时间多写unit test，就会提高code quality，无论是否用TDD。不过我现在这个project只有1/3的code有unit test，PM只要feature不要unit test，开始还是坚持写unit test，后来没时间了，只有。。。
另，我对纯TDD的process用着不习惯，还是先考虑implementation再考虑test cases。不知别人有无类似感受？

John.G

原帖由 newmike 于 2009-7-25 22:42 发表
如果时间充裕，TDD挺好，其实只要真肯花时间多写unit test，就会提高code quality，无论是否用TDD。不过我现在这个project只有1/3的code有unit test，PM只要feature不要unit test，开始还是坚持写unit test，后来没时 ...

同意...不过没有TDD的project后期发现bug再回去改也是一样的折腾时间和精力，还不如先花点时间写好unit test。

newmike

原帖由 John.G 于 2009-7-25 22:46 发表


同意...不过没有TDD的project后期发现bug再回去改也是一样的折腾时间和精力，还不如先花点时间写好unit test。

修bug本身倒是不可怕，如果code本身结构合理，即使是没有unit test，也不难refactoring。但是结构混乱的code，即使有unit test也还是big messy。至于没test且混乱的code，那就是噩梦。

我的看法是process和unit test只是工具，只有在高质量的设计上才起好作用。问题是在现实中，好的设计很难辨别，即使在前期我发现设计不良，也很难证明，只有工程后期，testing时通不过，才会设法弥补，不过，一般只会愈改愈糟。

[ 本帖最后由 newmike 于 2009-7-25 23:10 编辑 ]

leiz

原帖由 newmike 于 2009-7-25 22:42 发表
另，我对纯TDD的process用着不习惯，还是先考虑implementation再考虑test cases。不知别人有无类似感受？

TDD解决2个问题, implementation 和 unit tests. 在你考虑test case之前,应考虑的是你object的 user case, 这些就是你要test的functionality. 在你test每一个functionality的时候才要考虑test case.

newmike

原帖由 leiz 于 2009-7-26 14:12 发表


TDD解决2个问题, implementation 和 unit tests. 在你考虑test case之前,应考虑的是你object的 user case, 这些就是你要test的functionality. 在你test每一个functionality的时候才要考虑test case.

看来大家对TDD的理解是挺不同的。
我的理解：
1）TDD是process，一种agile风格的，由xp一些practices延伸来的process。而unit test，则是独立于TDD的best practice。不用TDD，照样可以用unit test，然而，没有unit test，则无法采用TDD。

2）user case和function，处在object和unit test不同的level上，与之对应的应是package/component和functional test。

3）我猜你要表达的其实和我前面说的一致，考虑顺序都是：
i. what need to do  (functionality)
ii. how to implement it (implementation)
iii. how to ensure the implementation is correct (test case)

4) 但是TDD建议的考虑顺序是不同的：
i. what need to do  (functionality)
ii. how to ensure the implementation is correct (test case)
iii. how to implement it (implementation)

实际中，我不习惯这种顺序，还是惯用3）的顺序思考。
大家怎么实际应用TDD的？交流一下心得吧。

[ 本帖最后由 newmike 于 2009-7-26 15:35 编辑 ]

Null_pointer

理论是很好的。
实践起来 还是看个人喜好了。
我就会选择在适当的时候test driven
大部分时候一边test 一边写 production code

newmike

原帖由 Null_pointer 于 2009-7-26 15:38 发表
理论是很好的。
实践起来 还是看个人喜好了。
我就会选择在适当的时候test driven
大部分时候一边test 一边写 production code

同意，用不惯不必勉强。

不太明白你说的‘一边test 一边写 production code’，比如， 你已知道需要有一个class，你是先考虑test case，还是先考虑implementation，至于写coding的顺序又如何？

另，不知大家的team里，谁做functional testing，是否是automatic/scripting functional testing?

rsystem

我们现在都说BDD,不说TDD

好事之徒

我的观点可能有点极端 但我认为无论什么process什么methodology 最后的关键还是人 （人月神话里已经总结得很清楚了）Ken Thompson 用他老婆带着小孩外出度假的4个礼拜就写完了第一个UNIX (he didn't need to know anything about TDD, he didn't even need to know OO or design patterns, 有些人持有更极端的观点 说OO 的目的其实就是为了使多数 medicore 的developer 不会造成太大damage).

newmike

原帖由 rsystem 于 2009-7-26 16:49 发表
我们现在都说BDD,不说TDD

BDD - 你是指Behavior Driven Dev? 它和TDD着重点又很不同了。不知你们的user story是谁写的，如果是你们的BA，恕我直言，不过是新瓶装旧酒，关键只是一个装字。如果是你们的客户写的，我倒是愿闻其详。

[ 本帖最后由 newmike 于 2009-7-26 18:39 编辑 ]

Null_pointer

原帖由 newmike 于 2009-7-26 15:50 发表


同意，用不惯不必勉强。

不太明白你说的‘一边test 一边写 production code’，比如， 你已知道需要有一个class，你是先考虑test case，还是先考虑implementation，至于写coding的顺序又如何？

另，不知大 ...

先考虑test case 那个就是 TDD了
我意思就是 go and see， implement 的时候想到 这个情况 就写test case。

还有我们公司是单独的testing department, script functional testing. Developer只是unit test

newmike

原帖由 好事之徒 于 2009-7-26 17:26 发表
我的观点可能有点极端 但我认为无论什么process什么methodology 最后的关键还是人 （人月神话里已经总结得很清楚了）Ken Thompson 用他老婆带着小孩外出度假的4个礼拜就写完了第一个UNIX (he didn't need to know an ...

同意人是软件开发最关键的观点。但是人月也不是说process/methodology没用，而是批评当时的流行观点 - 片面强调工程学，忽视人件。那是因为当时人们不太了解软件工程和普通工程的区别。而今天的优秀开发人员也是要有正确应用适合的process的能力的。比如同样的project, 人员同样优秀，应用不同的process/methodology，结果自然会不同。

newmike

原帖由 Null_pointer 于 2009-7-26 18:09 发表

先考虑test case 那个就是 TDD了
我意思就是 go and see， implement 的时候想到 这个情况 就写test case。

还有我们公司是单独的testing department, script functional testing. Developer只是unit test

我赞同你们公司对functional testing的做法。我们这有些funny，也是单独的test team，但他们基本都manual testing包括functional testing，只有做load testing时才写script。希望他们写functional testing script,他们不肯；我们的team leader出来说developer来写functional testing script；架构师出来说developer和tester一起写；到PM那倒是简单了，只要feature/function，连unit test都不用写！现实中的很多事情真叫人哭笑不得，TDD完全不管用。

[ 本帖最后由 newmike 于 2009-7-26 18:32 编辑 ]

newmike

LZ呢？也发表一下意见吧。

好事之徒

原帖由 newmike 于 2009-7-26 18:11 发表


同意人是软件开发最关键的观点。但是人月也不是说process/methodology没用，而是批评当时的流行观点 - 片面强调工程学，忽视人件。那是因为当时人们不太了解软件工程和普通工程的区别。而今天的优秀开发人员也是 ...

software development 还不是engineering, 跟其他工程领域相比，我们其实对怎样做software还不是很有idea, 我们只是以为我们知道。
http://www.codinghorror.com/blog/archives/001288.html

rsystem

原帖由 newmike 于 2009-7-26 17:51 发表


BDD - 你是指Behavior Driven Dev? 它和TDD着重点又很不同了。不知你们的user story是谁写的，如果是你们的BA，恕我直言，不过是新瓶装旧酒，关键只是一个装字。如果是你们的客户写的，我倒是愿闻其详。

我们的user story是plain english, 所以是人就能看得懂, 但是plain english也可以运行, 看有没有failure

rsystem

哦忘记了有时候也用中文写user story...类似这样的:

功能:加法
  为了避免一些愚蠢的错误
  作为一个数学白痴
  我希望有人告诉我数字相加的结果

  场景: 两个数相加
    假如我已经在计算器里输入6
    而且我已经在计算器里输入7
    当我按相加按钮
    那么我应该在屏幕上看到的结果是13

  场景: 三个数相加
    假如我已经在计算器里输入6
    而且我已经在计算器里输入7
    而且我已经在计算器里输入1
    当我按相加按钮
    那么我应该在屏幕上看到的结果是14

newmike

原帖由 rsystem 于 2009-7-26 19:33 发表


我们的user story是plain english, 所以是人就能看得懂, 但是plain english也可以运行, 看有没有failure

到底是谁写的？

是人能看懂没用，只是自我感觉良好。BDD的优势是客户自己直接定义UAT，不过我还没见实例呢。至于BA用plain english给developer写user story，很稀罕吗？运行plain english，用groovy写点DSL，怎么玩都成。

newmike

原帖由 好事之徒 于 2009-7-26 19:31 发表

software development 还不是engineering, 跟其他工程领域相比，我们其实对怎样做software还不是很有idea, 我们只是以为我们知道。
http://www.codinghorror.com/blog/archives/001288.html

然也。

newmike

再次呼唤LZ

leiz

原帖由 newmike 于 2009-7-26 15:31 发表
4) 但是TDD建议的考虑顺序是不同的：" i9 M; ?4 G% s& P
i. what need to do  (functionality)
ii. how to ensure the implementation is correct (test case): l$ ~- w* {5 m+ E" ~: Z  Y. t( O
iii. how to implement it (implementation)- L( W  }) A7 M- x

我想说的是,第2步,并不光是注重test本身,从test的角度发现object的user case,从而更好的设计你的code.而test case只是用来保证正确性的.
比方说,你的object是一个简单的calculator,你在想test的时候,先要想得是你要测试object的哪些functionality,比方说add,sub,mul,div, etc.,这样的话,从用户的角度来设计的你class,在完成这一步的时候,才会考虑正确性 -- 每一个的functionality的正确性

rsystem

UAT是啥? 术语真多... 头大...

leiz

原帖由 好事之徒 于 2009-7-26 17:26 发表
我的观点可能有点极端 但我认为无论什么process什么methodology 最后的关键还是人 （人月神话里已经总结得很清楚了）Ken Thompson 用他老婆带着小孩外出度假的4个礼拜就写完了第一个UNIX (he didn't need to know an ...

如果一个产品不用维护的话,只有一个人开发的话,可以不用任何高级的方法实现
用一些好的办法是应为在long run下成本会更低

ybbest

原帖由 rsystem 于 2009-7-26 20:03 发表
UAT是啥? 术语真多... 头大...

UAT=User acceptance testing