Common Questions when Adopting TDD

If you are new to TDD you may be struggling with some common questions such as:

• How much upfront design should I tolerate? 
• When writing a test you have to build interfaces and some classes to get it to even compile - how far do you let that go?

1. How much up-front design do you tolerate? How do you know when to stop (i.e. 'when algorithms start getting discussed, it's testing time')?
2. What about certain "I just know we'll need this" type stuff (i.e. putting a try/catch{Console.WriteLine(ex);} in your console main() method?)
3. When writing a test, in order to even get it to compile, you have to build an interface or two, a concrete class with some NotImplementedExceptions in it, etc. How far do you allow that to go?
4. If, during the middle of testing on a story, you realize that your up-front design wasn't correct, do you stop and discuss with your pair right then, do what you need to do and proceed, or do you pull back and go back to full pre-test design mode on that story?
5. When proceeding to a new story, you discover that a test you wrote for a previous story no longer reflects the requirements. Do you refactor that test immediately, mark it as ignored until you finish the current story and cycle back to the ignored one? Something else?
6. If the new story's requirements involve a slight tweaking to an existing test, do you tweak it, or make a new one and discard the old one (i.e. 'No changing existing tests!' or 'Only change if it's a minor compiler issue, but otherwise don't change it')?
7. If you're, say, building up your model and it passes tests, but you're seeing that it's infantile and that the next few upcoming stories will produce significant changes to produce a new emergent model, is it appropriate to step back and consider a larger refactoring, or do you keep plugging and make the changes into the existing model even if it could benefit from some housekeeping that is otherwise out of scope?

Derick Bailey shared his thoughts on the questions posted by Chad.  He was very careful to say these were his opinion and based on his experience - so your mileage may vary.  Here is one of his responses:

1. Enough to know what I'm supposed to build.
   You really need to answer this question based on your individual project. I recently built an enterprise integration project that took our core maintenance system and brought some disconnected operations into it. On this project, I did not have a lot of up front design. I knew that the system needed to operate in a disconnected mode, I knew it needed to be operational even when there was no one logged into the computer or running the software, and I knew that it needed to do bi-directional communication with the master maintenance system, to perform a limited set of maintenance related tasks. I started with a few assumptions / up front design - build a Windows Service to run the core process, build a client-server architecture to host the UI, build on top of a messaging system to support the communication needs. Beyond this, the functional requirements of those tasks drove the design of the project during the construction of the software.
   Conversely, I've worked with a team that was building a system for a laboratory, recently. With the requirements from the customer, the process that they requested, and the required conversion of existing data that the customer had; we required a large up-front design, to determine if the data conversion and functional requirements were going to be met by our proposed solution. The major design of the system was known up front, but the implementation was still a work-in-progress during the construction of the software.

If you are new to TDD these questions probably sound familiar.  Some of the best places to go for answers are to those who have been there before via a local user group or one of the many online developer-centric mailing lists.  If, on the other hand, you have TDD experience, please share some of your answers to these questions.