C
Chuck Remes
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
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