新西兰天维网社区

标题: Are you doing Test-Driven-Development(TDD) [打印本页]

作者: ybbest 时间: 2009-7-24 11:27:58 标题: Are you doing Test-Driven-Development(TDD)

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 时间: 2009-7-24 11:38:17

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

作者: ybbest 时间: 2009-7-24 11:42:30

http://www.youtube.com/v/wEhu57pih5w&hl=en&fs=1&

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

作者: leiz 时间: 2009-7-25 14:31:20

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

作者: ybbest 时间: 2009-7-25 15:38:48

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

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

作者: John.G 时间: 2009-7-25 22:41:42

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

作者: newmike 时间: 2009-7-25 22:42:12

如果时间充裕，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 时间: 2009-7-25 22:46:22

原帖由 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 时间: 2009-7-25 23:02:00

原帖由 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 时间: 2009-7-26 14:12:03

原帖由 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 时间: 2009-7-26 15:31:56

原帖由 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 时间: 2009-7-26 15:38:36

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

作者: newmike 时间: 2009-7-26 15:50:06

原帖由 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 时间: 2009-7-26 16:49:02

我们现在都说BDD,不说TDD

作者: 好事之徒 时间: 2009-7-26 17:26:52

我的观点可能有点极端但我认为无论什么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 时间: 2009-7-26 17:51:57

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

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

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

作者: Null_pointer 时间: 2009-7-26 18:09:52

原帖由 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 18:11:11

原帖由 好事之徒 于 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 时间: 2009-7-26 18:30:16

原帖由 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 时间: 2009-7-26 18:36:02

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

作者: 好事之徒 时间: 2009-7-26 19:31:41

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

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

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

作者: rsystem 时间: 2009-7-26 19:33:25

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

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

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

作者: rsystem 时间: 2009-7-26 19:38:32

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

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

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

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

作者: newmike 时间: 2009-7-26 19:51:58

原帖由 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:54:22

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

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

然也。

作者: newmike 时间: 2009-7-26 19:56:57

再次呼唤LZ

作者: leiz 时间: 2009-7-26 20:03:25

原帖由 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 时间: 2009-7-26 20:03:44

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

作者: leiz 时间: 2009-7-26 20:06:01

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

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

作者: ybbest 时间: 2009-7-26 20:21:31

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

UAT=User acceptance testing

作者: ybbest 时间: 2009-7-26 20:30:59

It is good to see people have different perspective on this.TDD is not silver-bullet to software development.Software crisis starts from more than 30 years ago,we still do not have solution yet.More than half of the world IT projects fails for various reasons.

Any software process have benefits and pitfalls,using it for the right project is key .My personal experience with TDD is that it is awesome.It is simply awesome.I don't have to explain why.Whether you like it or not , give it try.It will drive you nuts at the beginning( big learning curve).Things you need to know(Law Of Demeter,dependency injection,mocking,how to write testable code,why singleton makes your code untestable and how to mitigate the effects).Once you master it and you will love it.You will laugh at those people who still argue whether TDD is good or bad

作者: ybbest 时间: 2009-7-26 20:34:05

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

]
PM is not an excuse.Quality is the key.Without unit testing how can you make sure your quality.You will either make QA people spend more time to test your system.If you know fixing a bug in development time is much much much cheaper than fixing it at UAT or even after deployment.
However, it is your responsibility to convince your pm,spend a little bit overhead on test will provide much much much benefit later on.

作者: ybbest 时间: 2009-7-26 20:39:40

原帖由 newmike 于 2009-7-25 23:02 发表

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

我的看法是process和 ...

Totally agree what you said ,unfortunately we do not have better design at the moment.There is no way you can measure how better your code than my code.Software crisis still exists and we still try new things.TDD is one,so give it try.Let me know what other methods can you make software better.Having better design is too broad to make as an argument.

作者: ybbest 时间: 2009-7-26 20:44:17

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

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

In TDD,you need to write tests first and then write your implementation or you can say having all the tests fails and then write implementation to make it pass.
Benefits:
1.you need to have clear requirements to write tests but not production code.(Make you think whether the requirements is good enough for me to write tests ,if not I need to ask the BA or Client what are the actual requirements.
2.Safety net.(If you change your code ,how can you make sure it does not break other codes.Do not tell me you have fully tested because you can not even you can it takes days without unit testing)

[ 本帖最后由 ybbest 于 2009-7-26 20:48 编辑 ]

作者: leiz 时间: 2009-7-26 20:51:30

LZ 看上去对TDD比较了解了,我想添加一点的是,在performance很重要的application, eg. real time application,很多unit test上的实现是很困难的,不是不可能,但是添加了unit test实现上的困难性,从而让整个TDD过程很cumbersome

作者: ybbest 时间: 2009-7-26 20:53:15

原帖由 newmike 于 2009-7-26 19:54 发表

然也。

Yes.it sucks

作者: ybbest 时间: 2009-7-26 20:58:21

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

You can not list those outliers.Most of us are normal and doing normal jobs.

作者: ybbest 时间: 2009-7-26 21:00:46

原帖由 leiz 于 2009-7-26 20:51 发表
LZ 看上去对TDD比较了解了,我想添加一点的是,在performance很重要的application, eg. real time application,很多unit test上的实现是很困难的,不是不可能,但是添加了unit test实现上的困难性,从而让整个TDD过程很cu ...

Yes , you need to design your code so that you can test it .I suggest you to read google testing blogs.They got some genius there to talk about how to do it properly.

作者: leiz 时间: 2009-7-26 21:11:29

原帖由 ybbest 于 2009-7-26 21:00 发表

Yes , you need to design your code so that you can test it .I suggest you to read google testing blogs.They got some genius there to talk about how to do it properly.

Designing is the key, but the problem is that you need to choose between good design and performance in real time applications. For example, mocking object is too slow for some cases. If you use c++, mocking object are implemented using virtual call and that sometimes is too slow. But you are right about design, in normal case, a proper design will give you easy-to-test code.

作者: ybbest 时间: 2009-7-26 21:17:08

I think if you are geeky enough and hate what you can do with mocking @ the moment.You can develop a new open source Mocking framework for C++. :)

作者: leiz 时间: 2009-7-26 21:25:58

It can be implemented using templates, but it usually involves a management decision because not every c++ programmer knows template well enough. As far as I know, google code standard dont even allow templates. You see what I mean.

作者: ybbest 时间: 2009-7-26 21:29:33

Yes，I think it is more like limitations which current technology has.Hope more and more work will be done in this area.

作者: newmike 时间: 2009-7-26 22:06:11

LZ, very glad to hear your voice. I agree with most of your point, except the following stuff:

> PM is not an excuse... However, it is your responsibility to convince your pm...

Not agree with this point. It is not right the programmer take whole responsibility for Quality, it needs everyone, esp, PM & client allocate enough resource, esp, time to do so. However, most of time, only programmer worry about this. But do you think PM do not know that fixing a bug in development time is much much much cheaper than fixing it at UAT or even after deployment? This is not an issue which can be solved by convincing or TDD, it is just about MONEY & duty.

> In TDD,you need to write tests first and then write your implementation or you can say having all the tests fails and then write implementation to make it pass....

In fact, I am not worry about actual coding order at all - it can not be fixed anyway.
it is call TDD not Test first dev, right? My focus is on what affect of TDD to the design process. TDD more or less show a different approach to design a system, not top-down or bottom-up, a new dimension - let test consideration to drive design process. I am still looking for what is the benefit/drawback for the real projects(or which kind of project).

作者: ybbest 时间: 2009-7-26 22:17:44

原帖由 newmike 于 2009-7-26 22:06 发表
LZ, very glad to hear your voice. I agree with most of your point, except the following stuff:

> PM is not an excuse... However, it is your responsibility to convince your pm...

Not agree with t ...

Different companies got different approaches.In my companies we have practice lead to defend ourselves from those pm's shit(like do not write unit tests because of budget).Our practice lead will say while you can do it in this company.End of story.Our standard is all the project except presale prototype has to have tests.

Order of TDD
All I can say the best practice in TDD is to write test first.As a programmer you can do whatever you like.But most of people agree that the best practice in TDD is to write test and make all your tests fails and then write code to make your tests pass.That's why it is called test-driven.If you write production code it is not called test-driven.It is called writing tests t o test what I already had to make sure there are no bugs.
I do not define the best practice in TDD,Google or Bing TDD best practice you will find out.

作者: ybbest 时间: 2009-7-26 22:22:05

What is Test Driven Development?
TDD is a process pattern for constructing iterations of development projects that employ unit testing. It is a core tenet of “Agile Development”, specifically the Extreme Programming (XP) camp. When undertaking TDD, the API for the modules under development will ideally have been specified to a reasonable degree, for reasons which follow. Note that this somewhat conflicts with the principle of “Emergent Design”, another core tenet of the Agile/XP community.

The process pattern is roughly as follows:

1. Design the unit tests
2. Code/Generate the class and interface skeletons
3. Write the unit tests
4. Run the tests (all should fail!)
5. Code the minimum required to pass each test
6. Iterate

作者: newmike 时间: 2009-7-26 22:31:18

原帖由 leiz 于 2009-7-26 20:03 发表

我想说的是,第2步,并不光是注重test本身,从test的角度发现object的user case,从而更好的设计你的code.而test case只是用来保证正确性的.
比方说,你的object是一个简单的calculator,你在想test的时候,先要想得是 ...

同意。我关心的正是这么做的好处和局限。先写test case还是先写implementation，我不认为那么重要，方便就成。TDD本质上提倡一种新的设计思路，用testing的角度来驱动设计。我的应用体会是没有发现特别的好处和局限，和平时大家常用的user case->code->test思路没有显著的区别。大家在这方面有无发现显著的区别？或是什么project适合TDD的设计思路，什么project不适合？

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

作者: ybbest 时间: 2009-7-26 22:39:09

原帖由 newmike 于 2009-7-26 22:31 发表

同意。我关心的正是这么做的好处和局限。先写test case还是先写implementation，即使不那么重要，方便就成。TDD本质上提倡一种新的设计思路，用testing的角度来驱动设计。我的应用体会是没有发现特别的好处和局限 ...

No,no,no.
As I said before you can not write your tests if you do not have any clear requirements or you do not fully understand the requirements.

When you write implementation,it is called an solution to an requirement.You can write implememtation even though you do not understand the requirement or the requirement is not clear.

If you are writing implementation before tests , you are not test-driven.You are not fully utilizing test-driven development.My understanding for TDD is more like understand requirements and document the requirements in terms of tests.Implemented the requirements to make every test pass.

作者: newmike 时间: 2009-7-26 22:50:14

原帖由 ybbest 于 2009-7-26 22:17 发表

Different companies got different approaches.In my companies we have practice lead to defend ourselves from those pm's shit(like do not write unit tests because of budget).Our practice lead will s ...

Yes, you can convince your PM about unit tests, since your company has such policy & practice lead, otherwise......

Referring to the order of TDD, I agree that there is no best/defined practice for TDD, in fact, for most of agile practice, they are more like suggestions rather rules. Refer to the step 4, I wonder if anyone do this step more than 3 times, maybe someone do, but not me.

Would you like to talk more about how TDD affects the design process in your projects, or you think TDD just make coding order different.

作者: newmike 时间: 2009-7-26 22:58:13

原帖由 ybbest 于 2009-7-26 22:39 发表

No,no,no.
As I said before you can not write your tests if you do not have any clear requirements or you do not fully understand the requirements.

When you write implementation,it is called an s ...

You did not catch my point - I make my idea clear in a reply to
leiz

看来大家对TDD的理解是挺不同的。
我的理解：
......

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）的顺序思考。
.......

My first step is alway to get understand about functional requirement, no matter of TDD.

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

作者: ybbest 时间: 2009-7-26 23:06:50

I can understand where you are coming from.At the beginning I force myself to write test before implementation.(why? as I said before).I see the benefits and I keep doing this way.Refer to the step 4 , I do it all the time.My suggestion is to force yourself to write tests before implementation for 3 months to see the differences.I am sure you will.
Do not be offended ,everybody has his/her comfortable zone and reluctant to step out.Try changing the way you do it even though you are not comfortable with it .You will see the benefits.Once you see the benefits you will keep doing it.

[ 本帖最后由 ybbest 于 2009-7-26 23:09 编辑 ]

作者: newmike 时间: 2009-7-26 23:24:59

原帖由 ybbest 于 2009-7-26 23:06 发表
I can understand where you are coming from.At the beginning I force myself to write test before implementation.(why? as I said before).I see the benefits and I keep doing this way.Refer to the step 4 ...

Thanks for your suggestion.
As the principle you mentioned, there is no silver bullet in software engineering. To force yourself to do something differently over 3 months is really a way to change a old habit, however, it is just character difference between you & me, I am more interesting with real benefits or difference in terms of soft-eng beyond personal habit/comfortable.

作者: ybbest 时间: 2009-7-26 23:38:57

Real benefits are that you are using code to document code in terms of tests and you make sure you understand what is required before writing code.If you do not see these as benefits then I can not convince you to use TDD.
Because it is different and it needs time to get used to it.When you first start using it you will feel shit and ask yourself how stupid this way is.You need to convince yourself that it has benefits using it.I can not help you with it.
Well,there is nothing wrong with the order,it is more like whether you'd like to adopt TDD or not.

作者: newmike 时间: 2009-7-27 00:18:24

原帖由 ybbest 于 2009-7-26 23:38 发表
Real benefits are that you are using code to document code in terms of tests and you make sure you understand what is required before writing code.If you do not see these as benefits then I can not c ...

Thanks for your comments about TDD's benefits. It is quite helpful to get your options.

For the same thing, it is quite normal that different person get different idea. Finally, I just address my experience of TDD with a little more details:
1) I do follow the test-first code order at most of time, and do try code-first order as well (my first question is to find out why/whether the order is important), but no significant difference has been found so far, both way get the benefits you mentioned, and others like better spec/implementation isolation and etc, so I do not think coding order important, I believe these benefits comes from unit tests; In fact, both coding order is fine to me. The test-friendly code is different from implementation-only code anyway, as long as I know unit test have to be there, I will not implement in a way to be hard testing. It ensure quality, but double my development time, this is the reason PM say ignore it.

2) I found if make test concern driving design concern totally, the design process will be very different from the traditional approach, and I felt uncomfortable - more precisely, unsure what side-effects will be, not like top-down / bottom-up, we know them so well, both of good sides & bad sides, but Test driven design is not what I am confident with, it is new and strange.

Oops, it is very night, c u later and very happy to get so much useful share knowledge, we could have some meetings for these tech discussion.

[ 本帖最后由 newmike 于 2009-7-27 00:24 编辑 ]

作者: GongIsMine 时间: 2009-10-25 14:37:31

提示: 作者被禁止或删除内容自动屏蔽

作者: variable 时间: 2009-10-26 09:09:50

大家都加入NZ Software Developers群探讨一下吧。

作者: variable 时间: 2009-10-26 09:49:37

god I hate that guy's voice in the video

作者: newmike 时间: 2009-10-26 14:19:25

本帖最后由 newmike 于 2009-10-26 15:21 编辑

如有可能,谁组织个活动,大家见面讨论一下。

我常参加的一个tech group - The Auckland JVM Group这周四有一个关于testing & junit的讨论会，大家如有兴趣可以去听听：
http://www.meetup.com/auckland-j ... t/ce1p_grp/?rv=ce1p
免费，需注册，周四6PM，90%是洋人，侧重于Java平台。

欢迎光临新西兰天维网社区 (http://bbs.skykiwi.com/)