Test Driven Development (TDD) Tip

I'm a big fan of Test Driven Development (TDD). TDD is an Agile methodology where automated unit tests are developed before the feature is developed. By coding automated test before actually coding the feature, the developer is forced to think through how the feature should work. If you've ever developed manual test scenarios you know what I mean. Many questions come out of the wood works of one's mind when going through this process. Another advantage of TDD is that once the tests are developed the development mission become clear – code to the tests and once they all succeed you are done and ready to move on to the next item in the prioritized list of features.

However, TDD requires a bit of procedure built into it – especially with regards to Continuous Integration (CI) and deploying working code on a nightly basis. Both processes are vital to the success of a project. I encourage my team to check in working code daily; ideally multiple times per day. With each check-in the CI server builds the project(s). If the project fails to compile or the unit tests fail then the build is considered failed. At that point, everyone on the team gets an email stating the failure and fixing it become the top priority. This also applies to the nightly deploy process which compiles the code, runs the tests, deploys the project into a distributed environment where automated QA scripts are run. A failure at any point results in top priority work for the team the next day.

In case you haven't already deduced the problem, if a feature takes a week to develop and all the automated tests are written up front, then the CI and deployment processes will be in failure mode most of the time. Thus, there are three solutions:

1. Iteratively develop the tests. For example, in a single day a developer may create a few classes, some properties, and a few methods. Tests should be written to accommodate what will be completed today not for the entire feature (this is my preference).
   
2. The developer could develop all the tests with an "ignore" flag so the tests don't run.
   
3. Use a methodology other than TDD.
   

I'm interested in your thoughts and alternative approaches that you've seen.