[rspec-users] Shared contexts
wagner.andrew at gmail.com
Wed Nov 17 09:43:40 EST 2010
OK, in the face of chirping crickets, let me try to be a little more
concrete. Here is a start at trying to spec out some behavior for our fabled
I'd love to get some suggestions for improving how this is organized.
Specifically, there are a few different, but related, contexts like the ones
I've put in shared examples. Ideally, I'd like to figure out how to make
these contexts composable in some way, because the actions they're comprised
of are composable.
On Tue, Nov 16, 2010 at 1:07 PM, Andrew Wagner <wagner.andrew at gmail.com>wrote:
> Suppose we have this class:
> class MarbleMachine
> def insert color
> # process marble of color 'color'
> def press button
> # process a push of the given button
> def output
> # compute a result
> Let's presume here that the machine takes any number of marbles in any of 8
> different colors, and that it has a few different buttons that can be
> pressed. The output is highly dependent on what actions you take, in what
> order. Obviously, a bit of a silly example, but easier than explaining a
> complex, highly data-driven application.
> Ok, now let's think about writing some specs. We're really not interested
> in trying to specify every possible scenario. But there are a few scenarios
> that we know are important. For example, we know that the customer is very
> interested in what happens in the state the machine is in after the
> [:blue_marble, :medium_button, :black_marble, :orange_marble]
> What happens if you insert two green marbles after this? What happens if
> you insert a yellow marble and press the big purple button? etc.
> In addition, the customer is also very interested in what happens if you
> push the red button when the machine is in a variety of states.
> What I'm trying to get at, here, is that I want to share some complex
> contexts across specs while not varying the action I'm specifying. I also
> want to vary the action I'm specifying in a number of different contexts
> (which is more along the lines of shared examples). I don't really want to
> think about it in terms of the state that exists, because that's not useful
> from the customer's standpoint. To be sure that things are set up correctly,
> we need to be able to say what happened, not just what the state is.
> So, how would you organize your specs in a scenario like this?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-users