Chapter 12. Use Existing Seams

Michael Feathers introduced the concept of seams [WEwLC] as a framework for bringing code under test. A seam in our code gives us the opportunity to take control of that code and exercise it in a testing context. Any place that we can execute, override, inject, or control the code could be a seam. Seams are all over the place. Sometimes, they are so obvious that we do not even think of them as seams. Other times, they are subtle or arcane and we miss them. And sometimes, we introduce them in order to be able to exert the control we need for testing.

Now that we have seen numerous techniques for bringing code under test, let’s step back briefly and look at the big picture. This chapter roughly outlines an ordering of seam types within Feathers’ category of object seams, but with some extensions to non-object-oriented programming models. The order in which they are presented roughly conveys the order in which I feel they should be considered for use in bringing code under test. The order considers factors such as ease of use and the inherent coupling to other interfaces, classes, or frameworks that the category generally entails.

Like any attempt to sort heuristics, the order should not be taken as a strict set of rules, but rather as a suggestion that can be overridden with reason. Additionally, this chapter suggests an order of consideration for existing seams. Changing an existing design for testability requires a far more complex set of reasoning than a simple hierarchy.