Many times during a development cycle, you find bugs and/or receive new feature requests that you need to keep track of.  Typically, this is added to a list of some sort, be it a bug tracking system or just a post-it note on your monitor.  While there is certainly value in having items like this documented and tracked in a formal (or informal) fashion, I find it helpful to create a stubbed test that reminds me of my outstanding coding tasks.  

As an example of adding a "to do" test, consider the following scenario.  I am currently working on a system which allows the logging of activities; attachments can be associated with those activites.  While manually testing this system that is currently under development, I noticed that upon saving one of these logs, the attachment was not being saved.  Rather than add this to a list of todo tasks for myself - I went ahead and created a test called "ShouldAddAnAttachmentToExistingLogUponUpdate" that simply throws a NotImplementedException (for now).  (Note: I am using mbUnit, but any unit testing framework will work with this concept).

As a result, when I go to run all tests for my solution, I will see this exception and remember that I need to fix this bug by making this test pass.  In my opinion, this is a helpful way to keep track of the items that you need to fix and/or implement, as well as a great way to get in the habit of using test driven development.  Creating tests as "To Do" items reminds you to code the test and, subsequently, code the logic to pass the test.

There's been a big industry focus on test driven development over the past few years.  Many advocates of TDD make it a point to say that TDD is not really about testing, it's about design.  Writing tests before application code forces you to think about the goal(s) of the application code.  For example, what should the input to a certain method be, and what output should it supply?  TDD forces you to think in terms of inputs/outputs and code interaction.  What input should be provided to the callee, what output should be provided to the caller - essentially, how will multiple objects (e.g. classes, methods, etc) interface.  

I've recently started practicing TDD a bit, and have found that instead of always writing unit tests with some type of testing framework (e.g. nUnit), I sometimes create a console application that calls certain methods and reveals the output.  Granted, these are perhaps more "integration" tests than unit tests, as I'm using them to view database contents.  None-the-less, it got me thinking about TDD, and the notion that "Test"-Driven development isn't really about tests.  In my opinion, a more appropriate name might be "Client"-Driven Development.  I'm not referring to the clients that pay your bills, but the client portions of your application (e.g. the UI which calls another application layer).  There are clients at every layer of your app - the UI calls one layer, that layer calls another layer.  Each caller is a client, and when writing tests first, we need to think in terms of the "client", what it should input, and what the result should be.

Isn't CDD essentially the goal of TDD?