TDD assumes interfaces are defined already; how to cope?

Question

To write tests before code, you need to have a way to interface with the code. Tests tend to define interfaces well ahead of time so that tests can just be written.

But often developing a good implementation involves inventing a set of good inter-component interfaces, tweaking and remaking these interfaces many times. During this you either keep on rewriting good portions of test code, or allow tests to lag behind code.

Are there any best practices to alleviate this?

Answer 1

This sounds like the whole red-green-refactor loop. That is to say, TDD is - sort of - about this rewriting of interfaces. This keeps them lean and to the point. Once you get the hang of TDDing, and you write your tests interface-oriented and keep your objects small you shouldn't see much changing going on unless you hit on something unforseen and must adapt, which is the point of being agile (which is hopefully why you're TDDing)

It sounds sort of like you're defining whole interfaces in one go, though. Which would be wrong. One test should generate one function in the interface, and it's expected behavior. Your interface will grow with the test-suite, thereby minimizing further any back-patching.

Answer 2

Just as you write tests as if the code you are testing were already written, you can (and should) write them as if the interface were already written. That is the Design part - the most important part - of Test-Driven Design. You know what functionality you are about to ask for from your class under test; write the test as if that functionality were already there. The names and parameters you use now, in your test; what naturally occurs to you, thinking as a client of the code and interface being tested; these elements feature prominently in the design of your class and its interface.