Szczepan Faber wrote on worrying about the unexpected. By that he means that your tests try to step outside the specific assertion boundary, and try to identify "unexpected" behavior. He describes his views on state and interaction based testing, and when (and when not) to write these kind of tests. This is a good example on how fragile your test code can get.
It’s always amazing on how you can make things more complex, with very little effort.
Awhile ago, we had a logic component we wanted to write in TDD. It had a dependency on the registry, so we used Isolator to mock these dependencies. This was simple enough. And the outcome was brittle as a … very brittle thing. The tests passed, but we had to go in and change them over and over again. That was because the method calls changed, the order of calling changed, and so on. And every time we made changes to the internals, the test code had to change too. The tests knew too much about the internals of the code.
Newsflash: Over-specification is bad. And like many things in life, you need to learn that through trial by fire.
The problem gets worse when you’re doing TDD. If you find yourself going back and forth, changing expectations and code, you have a problem. You probably need to do some refactoring first (and some thinking never hurts, too).
And by "You" I mean "We", and especially "I".
