Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick

191.8

⇒

167.2

⇒

186.2

183.6

184.0

183.2

184.6

Tue, 18 Feb 2003

Is it useful to think of FIT fixtures as controllers?

This morning, while waiting for the alarm to go off, I was thinking about Rob Mee's style of developing test-first with FIT. He starts with a test, puts code to implement it in the FIT fixture, then over time refactors it out into the application proper. (I think I've seen Ron Jeffries and Chet Hendrickson do something similar.)

I've been doing a little Cocoa programming recently. Cocoa, derived from NextStep, uses what it calls a model-view-controller architecture. (It differs from the original Smalltalk-80 MVC, and I know the whole issue of MVC is confused.)

In Cocoa, controllers are classes that exist to decouple the views (which handle both user output and input) from the application model. Put another way, they serve to translate from the user-visible domain to the internal domain and back.

In a way, it seems that FIT fixtures exist to translate from the user-conceptual domain ("what I want this program to do for me") to the programmer-conceptual domain ("what the guts look like"). I wonder if there's any intellectual leverage to be had by imagining what we'd do differently if we thought of fixtures as controllers? What grabs my attention is that maybe we don't think of fixtures as incidental code, just there to make the tests work, but as a part of the architecture in their own right. Maybe interesting serendipity could arise?

## Posted at 07:21 in category /testing [permalink] [top]