TDD Bumper Shots.

The newest recognized syndrome in my test-driven experience is the three-cushion bumper shot.

The idea is that you have a test on class A. But what the test is really doing is testing that class C (connected to class A via class B) is working. Instead of (or in addition) to having a test suite for C, you end up building a complex framework of mock objects and setup functions to get C manuevered into place behind B and B put into place under A. Next, you end up poking at A in certain ways that will cause C to react, and you start to expose methods in A and B to evidence the changes in C. These remind me of an old game called "Black Box", but not in a good way.

This feels contrived and wrong when you do it. It makes you work harder than you ought to, and it makes you dig deeper than you should have to. It makes you wire the existing detailed structure of the system into your tests. It's clearly the wrong path.

Sometimes you get advice, and it sound reasonable enough at the time, but it doesn't really take root. This is one of those times. I was told that we should test low-level mechanisms directly, and then we should test that higher-level classes are correctly wired to use them. It really is good advice, but I had to recognize it in hindsight rather than foresight. Now I know what that mistake looks like and can avoid it in the future. Indeed, we don't need any duplicated tests, and we don't need the difficulty and stress of trying to hit three-cushion shots in our software testing. It can be simpler, and it needs to be.


I'm working on recognizing other pathological practices, like the Mother May I game. I'll try to report the rest as they become obvious to me.

!commentForm