Replace Technical Design Meetings With Behavior Tests

| Comments

If you’re frustrated by endless technical design meetings, try short-circuiting one with some behavioral tests.

Meetings hurt. They take precious time away from building things. Technical design meetings are especially painful because we know we could use that time to write code. Instead, we come out of the hour (or two!) bleary-eyed and with little to show.

If you feel this pain, try replacing some of those meetings with behavioral tests. These tests can demonstrate the interface or behavior you’re trying to design, then live on as verification and documentation.

I’ve discovered some ground rules for doing this:

  1. No business-folk. You’re writing code, not prose. This is for developers only.
  2. Be flexible. Your initial tests are brainstorms and straw men to get the conversation going.
  3. Keep your tests alive. It’s important that these initial tests survive through to implementation, and remain valuable as verification AND documentation.

An example: Pretend we’re building a web front-end for a system that books hotel rooms. The back end is responsible for looking up availability and is to be built by another team. We need to design the interface to be invoked by the web code, which has collected the information about the room, to the backend code, which can look it up. I might write an initial behavior test like this:

class TestRoomChecker(object):
    def should_get_available_single_room(self):
        checker = RoomChecker()
        room = checker.check(beds=2, start="12/1/2009", duration=4)
        assert room is not null

Even with this rinky-dink test, I’m communicating TONS of useful things to the backend team:

  1. The name of the method the front end will invoke to look for rooms
  2. That I want to send the date as a string, and not a datetime
  3. That I’ve forgotten about smoking rooms, accessible rooms, and bed size.

This is all great stuff that came about because I wrote my behavioral test before meeting with people to discuss technical details. Now when we do get together and discuss the test, I can add TODO’s directly in code to note the issues and immediately update my tests to reflect them.

It’s easy for someone from the backend team to look at this and point out all the flaws and defects. If you’re really feeling your oats, ask them to stay at your desk and write a few more with them looking over your shoulder. You’ll end up with a rich set of tests that define and verify the new interface.

blog comments powered by Disqus