This has been on my mind lately as I can clearly see the benefits of TDD. I can very easily see how tests could drive a good design if the developer has an idea of what the functionality should be. This may be an overly simplistic statement, but from everything that I’ve read, TDD advocates that you have no design beyond your project architecture and framework choices. That being said, I’d have to guess that even the most hardcore TDDers don’t have a completely blank mental design slate when they start working
My question is this: Can TDD be used in an environment where a senior programmer/designer/architect does a class and/or component design and then hands that design off to a junior developer to implement? In this case the tests would not be the primary driver of the design. I suppose the implementing programmer could implement that design using a test first approach. In that case is it still TDD, or is it something that would be better called Test Driven Implementation? Would something like this work in the real world, or do you think you'd end up with the worst parts of TDD and design up front?
I came across Roy Osherove's blog describing the various meanings of TDD:
What are the possible meanings of TDD?
- Test Driven Development: the idea of writing your code in a test first manner. You may already have an existing design in place.
- Test Oriented Development: Having unit tests of integration tests in your code and write them out either before or after our write the code. Your code has lots of tests. You recognize the value of tests but you don't necessarily write them before you write the code. Design probably exists before you write the code
- Test Driven Design(the eXtreme Programming way): The idea of using a test-first approach as a fully fledged design technique, where tests are a bonus but the idea is to drive full design from little to no design whatsoever. You design as you go.
- Test Driven Development and Design: using the test-first technique to drive new code and changes, while also allowing it to change and evolve your design as an added bonus. You may already have some design in place before starting to code, but it could very well change because the tests point out various smells.
After reading that, it is fairly clear that the Test Driven Design flavor of TDD probably isn't the best fit in this environment, but the Test Driven Development flavor would probably fit.