Continuing last night’s wobbly muse on graceful and awkward collaborators…
In the light of day, I think I see four possible responses to the situation when your new code depends on an awkward collaborator or collaboration:
- Ignore it (possibly just for now). Write your test anyway and suffer the expense. This is a legitimate judgment, tho one the hardcore among us have to be dragged kicking and screaming towards.
- Don’t automate a test for it. Again, entirely legitimate, and actually more common than just ignoring it for old hands, tho less so for noobs. Use old-fashioned GAK testing instead.
- Re-arrange around it. Change your code so that the part you most want to test no longer needs the awkward collaborator. This is bog-standard hardcore TDD, extremely common.
- Isolate and fake it. Use one of the several means to "for the purpose of testing", not use the actual awkward collaboration, but some cheap simulacrum of it. Also extremely common — a lot of old hands might say it’s overused and prefer the third choice.
The third and fourth choices "re-arrange" and "fake" are by far the two choices most TDD’ers prefer. But I don’t know of anyone who never ever responds with "suffer" or "GAK test". (GAK = geek at keyboard. It’s a geepawism to describe what most non-TDD’ers do to satisfy themselves that the coder and the code say the same thing.)
I want to reach back to the premises to show they relate to this.
The whole conversation is predicated on the money premise. If TDD were about intellectual purity and not shipping more value faster, we would always choose to ignore the awkwardness and suffer the owwie. Many new-to-TDD teams do just that. What then happens, sooner or later, is that the cost of doing the tests eventually outweighs their benefit. The team simply stops doing TDD. The process of stopping is spread out over a long painful time, and it tends to happen more or less insensibly.
It begins when we start honoring team agreements around testing "chiefly in the breach". The chaining premise is invoked by the "isolate and fake" choice and maybe partly by the "rearrange" choice. we are testing part of our system and agreeing to be satisfied that we’ve done enough to be "sure".
Of course, the choice itself has judgment premise written all over it. it takes a human using intuition, experience, technique, theory, the whole vague schmoosh of non-computable consciousness to see and decide on any of these choices.
And finally, re-arrangement suggests the steering premise, and if you’ve done it enough times it leads to pre-arrangement, which is the center of that premise. The reason the steering premise is so important is because it encapsulates and crystallizes so much TDD experience. We can eliminate or mitigate an enormous amount of awkwardness in advance, if only we’re alert to it and willing to address it.
And the morals of the story are . . . 1) Don’t start a muse too late at night. 2) Awkward collaboration is normal in real-world TDD. 3) Notice awkward collaboration and choose to do something about it.
Thanks, and have a pleasant day!