I remember twice in two Enterprise web  base projects , by the
beginning of the project, we decided to develop the systems in Test
Driven development  way.

Test Driven Development(TTD):
• Think about what you want to do.
• Think about how to test  it.
• Write a small test. Think about the desired API.
• Write just enough code to fail the test.
• Run and watch the test fail. (The test-runner, if you're using
something like JUnit, shows the "Red Bar"). Now you know that your
test is going to be executed.
• Write just enough code to pass the test (and pass all your previous
tests).
• Run and watch all of the tests pass. (The test-runner, if you're
using JUnit, etc., shows the "Green Bar"). If it doesn't pass, you did
something wrong, fix it now since it's got to be something you just wrote.
• If you have any duplicate logic, or inexpressive code, refactor to
remove duplication and increase expressiveness -- this includes
reducing coupling and increasing cohesion.
• Run the tests again, you should still have the Green Bar. If you get
the Red Bar, then you made a mistake in your refactoring. Fix it now
and re-run.
• Repeat the steps above until you can't find any more tests that
drive writing new code.

We provide an infrastructure for developers to made it easy unit
testing and set some policy for this purpose. The idea of Testing
First, Refactoring and Continuous Integration was working well but
after some weeks, by the lack of time and reaching deadline/ delivery
time, bad coaching and so on, developers got lazy to write unit
testing and finally completely forgot this development process.

Test Driven Development provides a means of ensuring that the code
developed as a team will work as expected, and minimizes the time
spent consolidating and testing the application (Functional testing,
load testing, Code Analysis, Unit testing, profiling and UAT testing).