Hi,

 I have used both JUnit and NUnit and fornd them very helpful... They
are good for unit testing the modules and u can check that nothing has
broken by the new changes introduced in your code .

Infact, I would like to add this in good programming practices... this
is reduces time and effort put in on discovering that there was some
bug introduced by some minor change in a method.

The first thing you will need to do is define what test-driven development
is. I have talked to many people and get different options on what TDD and
other buzzwords mean. Just yesterday I interviewed someone who worked at a
company that used extreme programming and TDD. When I probed him about it,
he said that they did pair programming; two people, one a tester and one a
programmer. The programmer would write the code and the tester would write
JUnit code.

You talk to the TDD people in the testing newsgroups and they will tell
you this is not TDD. From what I have read most people are saying they are
doing TDD, extreme programming, agile development, etc. but the experts
would disagree.

That said, we are not TDD but we use JUnit. Some of our older projects now
have 47,000 JUnit test cases. We build nightly and tests are run as part
of the build. It is great for spotting when someone forgets to check
something in or a Windows user has mixed case (wouldn't affect Windows
tools) filename. The nightly build will run on Windows and UNIX so we see
the build break and someone is usually on it within a few hours.

Developers can also schedule builds and have the entire suite of JUnit
test cases run to make sure what they are doing is not breaking anything.

I've worked at other companies that did not use automated unit testing and
found many more defects were detected much later in the SDLC. Last
company, projects NEVER came in on schedule. They were usually not even
close. I would often see one group of developers change an interface or
side-effect that dramatically affected other teams using their APIs. This
would be something that a simple unit test should have caught but often
was caught by the test team after a full build and release; often weeks
after the change had been made.

On the other hand, I have seen teams that have a full suite of unit tests
but the highest rate of defects in a company of other teams. In other
words, having automated unit tests does not guarantee you have GOOD
automated unit tests. Until we did an analysis on defects over a number of
projects everyone assumed the team with thousands of automated tests was
the best team. Turns out that between 7% and 12% of defects were found by
customers on most teams but the team with automated testing had
consistantly over 20% of defects found by customers.

The automated tests lulled them into a false sense of security.