From: Chuck Remes <cremes.devlist@...>
Date: 2008-08-12T11:37:08+09:00
Subject: [Q] statemachine gem and unit testing

I've been using the statemachine gem [1] to build out some finite  
state machines for some work I am doing. I generally use rspec for  
most of my spec driven development, but I confess to having a bit of  
trouble wrapping my head around how to write specs for these  
statemachines.

For very simple 1 to 3 state machines, spec'ing the behavior is  
relatively simple. However, when the machines start getting more  
complex with nested superstates and more than a few transitions,  
spec'ing the behavior quickly gets out of control. Throw in a few  
decision states that can branch 2+ ways and my head is fit to explode.

I've been writing the specs iteratively. Each time I add a state, the  
#before block gains a few more lines to "drive" the machine to that  
specific state so I can test its behavior. Obviously this block gets  
pretty unwieldy after just a few semi-complex states. The specs that  
ship with the gem are not much help in this regard; they are very  
simple.

The obvious answer is to decompose every machine so none are larger  
than 3 states (or so), but then it pushes the complexity out to  
handling the interaction between those machines. Another approach  
would be to break encapsulation and allow the specs to setup the state  
directly without "driving" the machine to populate the values, but  
that just feels *wrong*.

Any ideas? Example code would be appreciated! :)

cr