Test-driven development is addictive, it works like Facebook and checking your email. It takes a very little effort to get a tiny endorphin kick. Red, and tap-tap-tap, green again. "I'm good!".
So the tests keep you going. And you take the Test-Driven-Development at face value. You keep adding stuff to your interface to give your tests something to check, then you test this also because if they fail, the rest of the tests are not worth squat. And this is a part of the whole point, isn't it? The testing should drive forward a good architecture? Keep on testing every single class and function until the software emerges from the test...
Tests cannot think for you - they cannot drive you anywhere, the only one driving is you, and that is in an endorphin crazed stupor. So snap out of it, and get your eyes on the road.
The architecture is the guide that will tell you where you are going, and the interfaces are what is going to be tested. I don't care if behind that interface sits four little classes playing hopscotch and conkers. Let them play, we will test how they fit in with the other interfaces.
And no, this doesn't mean that you should double up on your interfaces, making an interface for every gritty little detail in your app. Every time you make an interface it should be because this is a place where one component faces another and that they might be replaced. If your tests go any deeper than that you are only testing implementation, making it harder to change it when that time comes (and it sometimes does)
You test the use cases (or user stories, who cares?), you test your corner cases and your contracts. Whenever you stray outside of these borders, you are heading towards a test-driven derailment.