[rspec-users] Cucumber step or model spec?
dchelimsky at gmail.com
Mon Jul 20 19:04:16 EDT 2009
On Mon, Jul 20, 2009 at 5:58 PM, David Chelimsky<dchelimsky at gmail.com> wrote:
> 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.
Afterthought (or two):
You asked about cucumber scenario vs model spec and I responded from a
wider viewpoint. I think the same thinking applies to the scenario and
the model, though in that case, the expected outcomes are actually
different (application renders stuff on a page, model returns the
This is actually a perfect example of when it's good to have view
specs because the view template is probably the same view template
whether the app is displaying active products, inactive products, or
products that shipped last Tuesday. If the view fails to do its job,
three scenarios will fail. Perhaps they'll fail in such a way that you
can quickly isolate the point of failure. Or, perhaps you'll not be
sure whether the problem lies in the view, the controller, or the
model. In this case, being able to see passing specs for the view
would help point you to the other components.
Food for thought.
>> Thanks in advance,
>> rspec-users mailing list
>> rspec-users at rubyforge.org
More information about the rspec-users