[rspec-users] Cucumber step or model spec?

David Chelimsky dchelimsky at gmail.com
Mon Jul 20 18:58:56 EDT 2009

On Mon, Jul 20, 2009 at 5:30 PM, Marcelo de Moraes
Serpa<celoserpa at gmail.com> wrote:
> Hello list,
>  I have an example/spec that relates to the Product#index view and
> says "it should display only the active products". The thing is the
> logic to filter the active products should be in the model, and not on
> the view, since the view should be "dumb". I just realized that, and
> what I think is, even though this statement has business value, it is
> not lower level enough to be a view spec, nor a model or controller
> spec -- it should be a cucumber step, if any.
> Could someone enlighten-me, here? :)

Hi Marcelo,

This is a point of confusion for many, so you're not alone. I'll offer
my take, though I know there are others who see it differently.

I use Cucumber for specifying application behaviour and RSpec for
specifying lower level component behaviour. In the scenario you
* the application's job is to show only the active products
* the view's job is to display any products it is given by the controller
* the controller's job is to ask the model for the active products
* the model's job is to supply only the active products

So for me this is not an either/or question. Each underlying component
has a responsibility, and the result of the three components doing the
right thing adds up to the application behaving correctly.

Now, it happens that the outcomes we expect from the application are
the same outcomes we expect from the view. Many see this as
duplication, and if you agree with them, then you still may want a
cucumber scenario + a controller spec + a model spec.

For me, even though they appear to be overlapping, they are not. The
outcomes are the same, but the inputs are different. The scenario says
the application has to show x given some inputs. The view spec says
the view has to show x given some data supplied by the controller.
Different behaviour.

Now the last question I'd ask myself is whether the duplication in the
expected outcomes in the scenario and the view spec buys me anything,
and that really depends on how complex the view is, and whether I
anticipate doing much refactoring with it (moving partials around,
etc). One approach would be to err on the side of less overhead, but
then when I do go to refactor, make sure there are relevant view specs
in place before I do.


> Thanks in advance,
> Marcelo.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list