Beautiful Code

Chapter 6. Framework for Integrated Test: Beauty Through Fragility

Michael Feathers

I have some ideas about what good design is. Every programmer does. We all develop these ideas through practice, and we draw on them as we work. If we’re tempted to use a public variable in a class, we remember that public variables are usually a symptom of bad design, and if we see implementation inheritance, we remember that we should prefer delegation to inheritance.^[4]

Rules like these are useful. They help us move our way through the design space as we work, but we do ourselves a disservice if we forget that they are just rules of thumb. If we forget, we can end up with design where we are “doing everything” right, but we still miss the mark.

These thoughts were driven home to me back in 2002 when Ward Cunningham released Framework for Integrated Test (FIT), his automated testing framework. FIT consists of a small set of elegant Java classes. They maneuver in a path around nearly every rule of thumb about design in the Java community, and each little turn that they make is compelling. They stand in stark contrast to design that just follows the rules.

To me, FIT is beautiful code. It’s an invitation to think about the contextual nature of design.

In this chapter, I’ll walk through one of the earliest released versions of FIT. I’ll show how FIT deviates from much of the current accepted wisdom of Java and OO framework development, and describe how FIT challenged me to reconsider some of my deeply ...