rspec users - Nov 2010 - Shared contexts

Suppose we have this class:

class MarbleMachine
  def insert color
    # process marble of color ''color''
  end

  def press button
    # process a push of the given button
  end

  def output
    # compute a result
  end
end

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
sequence:

[: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...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20101116/717dd17b/attachment.html>

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
MarbleMachine:

https://gist.github.com/703446

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''
>   end
>
>   def press button
>     # process a push of the given button
>   end
>
>   def output
>     # compute a result
>   end
> end
>
> 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
> sequence:
>
> [: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...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20101117/52be262a/attachment.html>