What about my failing test?

After all, it turned out that my modified interceptor was not behaving correctly. Woah, wait a minute... didn't we have a test for that? Yes we did.

Yet, the user test failed.

What did I write the tests for? was it only an addictional burden, like someone suggests here? On the contrary. Well, when you write a test you actually are stating that "given X, when Y then Z". Unit tests are about "when Y, then Z", as when you write them you are supposed to know what X is (otherwise it would not be given). As I positively knew that the "when Y, then Z" part was working, the diagnosis was easy: my assumptions were wrong. A couple of clickety-clackety-clack and I collected the necessary data to build up the fixture. Ta-daaa! (yes, another red-green-refactor cycle followed).

TDD is a time saver, not a burden. And you don't need to be a master of design, like Brett suggests, as TDD forces you to concentrate on desing, even at an unconscious level. Whenever you think "how the hell am I going to test that?" the code is suggesting that you're taking a wrong way. Your tests are the first clients of your classes. Treat them well, or else they will stop buying. And finding a new customer is much more expensive than keeping the ones you've got, which means that you won't write tests. It's a descending spiral: keep out of it.