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 编辑 ]

newmike

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

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

variable

god I hate that guy's voice in the video

variable

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

newmike

原帖由 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 编辑 ]

ybbest

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

原帖由 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

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

原帖由 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 编辑 ]

newmike

原帖由 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.

ybbest

原帖由 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

原帖由 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

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

ybbest

原帖由 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.

newmike

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

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

leiz

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

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

原帖由 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

原帖由 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.

ybbest

原帖由 好事之徒 于 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

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


然也。

Yes.it sucks

leiz

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

ybbest

原帖由 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 编辑 ]

ybbest

原帖由 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

原帖由 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

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

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

UAT=User acceptance testing

leiz

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

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