May 8, 2008

...Learn TDD with Codemanship

Executable Acceptance Tests Could Drive Development Rather Than UI Mock-ups

Gojko Adzic is a jolly nice chap who offers some jolly sensible advice about how we can use acceptance tests to act as executable specifications - described entirely in business terms - to drive the design and implementation of our software.

He's dead right, of course. So right, in fact, that maybe he doesn't know how right he is. I would advocate going that extra step further in this approach: I would design and implement the logic of my example before I even think about user interface design.

Acceptance tests captured using a tool like FitNesse, for example, could specify the behaviour of the business services layer of our multi-tiered applications. It is possible to use these executable tests as a surrogate user interface, allowing us to explore and implement the business logic of user interactions and user workflow without so much as a text box being drawn.

These logical interaction specifications can then be used as a formal basis for UI design so that users can execute the same workflows through a friendlier, snazzier, sexier interface.

Over lunch I mentioned this as a possible approach, to which my colleague David quite rightly pointed at that most users need a visual UI model to help them understand the underlying logic. He's damn right, of course. Users need some way to visualise complex behaviour, data and rules. We share a semantic understanding of standard UI technology - forms, buttons, text boxes, drop-downs, grids and so on. We know what they are, and we generally know what they can do. So we can describe system behaviour in terms of the internal conceptual model of the user interface we share.

The problem with this approach, though, is that we have a tendency to get attached to the first design we come up with. So when we present users with a UI design in order to explore the requirements, we've actually jumped straight to a solution before we've had a chance to explore and understand the problem. And we often get stuck with that first naive design, leading to some very bizarre, counter-intuitive and clunky applications.

But there are other ways to visualise information systems. You can implement search algorithms using cards and filing cabinets, for example. You can create a working library system using books, boxes, paper and pencils. I'm a big fan of this kind of tactile modeling, where we collaborate using tangible, visible objects to explore the logic of our systems, getting the system to work in some mechanical form before we think about how it be implemented best as software.

In this sense, we can be deeply domain-driven, immersing ourselves inside the systems we're trying to model and effectively playing the role of the internal workers (processors) who execute the information workflows. Document that understanding with photographs and videotapes, and it could neatly feed into the kind of executable specifications Gojko talks about.

I've never put the two practices together, though, so I'll be very interested to find out how it would work for real. I suspect it would work just dandy, though.

Which is nice.

Posted 13 years, 1 month ago on May 8, 2008