This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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.
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.
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).
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
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com