Test-Driven Development

[Pradeep bhatt]

Hello Vincent,
What is Test-Driven Development mentioned in chapter 4?

[Stefan Bell]

Test Driven Development - is when you write the test before any code is writen. You know what the code is supposed to do (business rules) so you have the information to write the tests ahead of time. Then you make changes to the test as the rules change.

[Pradeep bhatt]

Stefan,
Isn't that how usually how we do the testing?
Is there cases where we do write test cases after coding. If yes, why and when is it done.
Thanks for your help.

[Pradeep bhatt]

Do we write test cases after writing use cases?

[Stefan Bell]

I am not the best person to answer this because I rarely use TDD. I get the use case, sometimes a model, and then code code code. After I am finished coding I write junit tests, to check the code and keep in Ant scripts. With TDD you would write your junit test and then code and when done coding run your test to make sure it works.

[Lasse Koskela]

Isn't that how usually how we do the testing?

I wish. Most Java projects out there probably don't write automated tests or write them poorly (for instance, writing JUnit tests for only the simple bean classes that are easy to do, not for the classes which really need the tests).

[Pradeep bhatt]

http://www.theserverside.com/home/thread.jsp?thread_id=22259

[john guthrie]

another answer. test-driven development is a very good book by Kent Beck
Test Driven Development By Example

[Surasak Leenapongpanit]

"Test Driven Development: By Example" is a good book but it isn't the practical book.

[Lasse Koskela]

This is the practical guide... Highly recommended, by the way.

[Fintan Conway]

Originally posted by Pradeep Bhat:
Stefan,
Isn't that how usually how we do the testing?
Is there cases where we do write test cases after coding. If yes, why and when is it done.
Thanks for your help.

Hi Pradeep,
The "traditional" way of coding is to get requirements, write the code, then remember that we have no test plans written for the code, write test plans, run integration and system tests. Any unit tests are done 'on-the-fly', i.e. whatever the programmer can think of as he writes the code - if any unit tests are done at all.
The drawback to this method is that unit tests may be skipped, the programmer is testing after he has written the code - so may subconsciously pick only tests that will pass the code he has written, the unit tests carried out are not documented anywhere.
Test Driven Development forces the programmer to write unit tests for his code before he writes any code. This forces the programmer to think of appropriate tests / failure conditions before he has any code / way of proceeding embedded in his brain. The code he writes for the test provides documentation for his unit test, as well as a means to exactly reproduce the test. Since the programmer must think about unit tests before writing the programs, he is less likely to skip tests, especially as he builds up his code by testing for small things and then adding to the code to make these things work.
HTH,
Fintan