@Poster, so are you volunteering?

candylips:

TDD is a waste of time and terribly difficult to do right in d purist form.

If your application is well designed, you will find that the Unit Tests are no more than calls to the actual business logic (the engine so to say). Since you are a Java person, I know you can understand when I say the Unit Test component simply replaces the Web-layer calls (say in your Struts2 Actions) but with extra code for assertions.

With this in mind, you should see the value of Unit Tests which already provide a use-case check versus requirements even before the Web-layer is complete. It's like having a test framework for your Jet engine in a lab before you've completed the airplane fuselage (which is actually how engineers test engines). You don't wait till the airplane is complete to test the engine; and as a matter of fact, the test of the engine comes first since it's the most important component after all.

Given any application, you have a finite set of use-cases/requirements. You should then be concerned about coverage and completeness. You don't just want to develop an application (non-trivial that is) without having exhaustively tested ALL the use-cases; as a stable application does not come about by simply keeping your fingers crossed. So how do you do this? TDD is just one of the ways you do this. You could also employ a team of human testers to exhaustively test; but with the associated drawback of human error and oversight.

TDD effectively tests your understanding of the requirements, and the completeness of your implementation.

This is my own take on this. I do not believe testing is a waste of time on my project, infact it is one of the most valuable thing a developer can do for so many reason and i would try to list some.
1. it help to understand the problem domain better as when you think about how to test an application even before it is written, it forces you to ask the right questions.

2. It also help for maintainabilty and support, what happens when you come back to a piece of code you have written a lot of time ago.

3. Also when you add a new functionality it acts as a safety net to ensure that you havennt broken anything.

4. It also help to ensure that you only write the minimal code that is needed to solve the problem at hand, as you only need to write code to make the test pass.

Also @seun said it is extra piece of code, you would not normally deploy your test code to the production env so it is not extra code, it is only to ensure that there isnt any broken functionality in your application.

I believe there is only one condition which should make a developer not write tests for their code, if the application is so small as in just a page of code and it is only maintained by you, saying that i would still write tests.

There are several levels at which which can do testing

1. Unit testing which is at the lowest level
2. Integration testing
3. Acceptance tests (which is done at user interface level)

And i believe every project should be testing at these 3levels. see Mike Cohn testing pyramid for how we should be distributing our testing efforts at the different levels. (http://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid)


I did a talk on testing some months ago and i have tried to attach my presentation to this post(its not the full presentation as there is a 200k limit). I hope this is useful to someone.



Saying all this , it is a not an easy craft, it takes a lot of time to learn how to do it right without going over the top ......

logica: If your application is well designed, you will find that the Unit Tests are no more than calls to the actual business logic (the engine so to say). Since you are a Java person, I know you can understand when I say the Unit Test component simply replaces the Web-layer calls (say in your Struts2 Actions) but with extra code for assertions.

With this in mind, you should see the value of Unit Tests which already provide a use-case check versus requirements even before the Web-layer is complete. It's like having a test framework for your Jet engine in a lab before you've completed the airplane fuselage (which is actually how engineers test engines). You don't wait till the airplane is complete to test the engine; and as a matter of fact, the test of the engine comes first since it's the most important component after all.

Given any application, you have a finite set of use-cases/requirements. You should then be concerned about coverage and completeness. You don't just want to develop an application (non-trivial that is) without having exhaustively tested ALL the use-cases; as a stable application does not come about by simply keeping your fingers crossed. So how do you do this? TDD is just one of the ways you do this. You could also employ a team of human testers to exhaustively test; but with the associated drawback of human error and oversight.

TDD effectively tests your understanding of the requirements, and the completeness of your implementation.

+100

lordZOUGA: seriously guys.. Tests? Tests is something you must write for every program. every programmer must have written tests in someway or the other, knowingly or unknowingly. That it is given some fancy name doesn't make it any special than it is. It's jus a way to verify that your code won't crash given a set of data. Tell me which programmer that doesn't do that?

Those fancy names determine whether or not you are doing things the right way. For instance if I talk about logging, it might sound like another fancy term to an ignorant programmer. But after further explaining, his eyes may light up and he might say he does logging using the standard "System.out.println" calls. Well-trained Java programmers know that's not the proper way to do logging.

logica: Those fancy names determine whether or not you are doing things the right way. For instance if I talk about logging, it might sound like another fancy term to an ignorant programmer. But after further explaining, his eyes may light up and he might say he does logging using the standard "System.out.println" calls. Well-trained Java programmers know that's not the proper way to do logging.

I understand what you mean but a good programmer should always know what he/she wants, he should know that what he read in a book is just a loose guideline to how things are done and that strictly following what is written will leave him stranded in this very dynamic field. I write tests but I don't give a damn about what its called. Maybe, someday, some random guy will give my style a name then you guys will argue about it on some random thread. I actually thought that the thread that will have the most discussions is the summer of code thread instead you people are here talking B.S about tests.

lordZOUGA:
Maybe, someday, some random guy will give my style a name then you guys will argue about it on some random thread.

Good luck to you on that. But I will tell you a little secret - those who come up with inventions/ideas/concepts do by studying other inventions and either building on them, or simply by understanding them in detail allowing their horizon to expand. You will NOT see anybody invent anything without a proper understanding of related ideas/concepts.

lordZOUGA:
I actually thought that the thread that will have the most discussions is the summer of code thread instead you people are here talking B.S about tests.

Surely, you don't expect that we all by default should be interested in the "summer of code" thing. I have more than enough projects on my hands right now and I can only come on here to discuss on occasion (and not just any random thread but only those that pique my interest). I am not obliged to partake in anything more than discussions.

A-ZeD:
Never done any unit testing.. Hope to peep and see if its a better way asap.

[img]http://www.50centloseweight.com[/img]Yeah!!