August 9, 2013
Follow me on Twitter


Test-Driven Design is facilitated by several kinds of objects which substitute for real objects and which exercise the system or probe the behavior of other objects. This matters because real systems use objects that you don’t want the test to exercise. If every test creates elaborate windows and reads large files, your tests will be slow. If the system involves alarms or databases or sprinkler systems, your tests are going to be uncomfortable.

Two categories of test objects are widely known.

I’d like to propose a third useful category, the Blunt Object. A Blunt is a subclass of a real object; it does everything the real object does except it removes behavior you don’t want in a test.

For example, a BluntSprinklerController is a subclass of a real SprinklerController and inherits almost all of the parent class behavior. But we do override two methods, RingAlarm() and ActivateSprinkler() — in each case doing nothing instead of actually making noise and extinguishing fires.

Blunts are as easy to write as stubs. Indeed, they’re often easier, since often you only need to override one or two methods. Blunts let you run tests with real collaborators, potentially reducing integration problems. Of course, Blunts have drawbacks:

Blunts are a very simple idea, of course, and everyone who writes tests is likely to have used them. But I’ve not seen them discussed explicitly and I do like the name.