[rspec-users] Working outside-in with Cucumber and RSpec

Ashley Moran ashley.moran at patchspace.co.uk
Sun Oct 26 06:39:12 EDT 2008

On Oct 26, 2008, at 12:03 am, Ben Mabey wrote:

> I agree with most of this.  For a purely RESTful controller I like  
> to use a plugin, like make_resourceful, that will take care of all  
> the boilerplate code that becomes very tedious to spec out and  
> write.  Since the plugins are tested I can just rely that coverage  
> alongside my scenarios going through the full stack.  However, once  
> I need to go out of the ordinary RESTful controller I usually always  
> still write specs for those actions using mocks.  My two reasons for  
> doing this is a) allow for interface discovery with mocks and b) to  
> prevent logic from seeping into the controllers.  Writing code  
> examples for controllers in a purely interaction-based way can be  
> laborious and it becomes extremely painful if you put actual  
> business logic in them.   I think that pain is a good thing because  
> it reminds less experienced people on your team (and more  
> experienced people too sometimes :) ) that controllers shouldn't get  
> too big and that they should be pushing the responsibility into  
> other objects (be that AR or regular ruby objects.)
> So while I agree completely that controller specs don't offer  
> regression value over scenarios I do place more value on the design  
> aspect I think they provide.  In the past I have been able to detect  
> feature envy and a number of other code smells within my controllers  
> via my controller examples that I don't think I would of noticed and/ 
> or been motivated enough to refactor them into the right level.   
> Again, I can totally understand your point of view and even agree  
> with it.  I think if a team is experienced and disciplined enough  
> then writing controller specs could be skipped... just keep a look  
> out for "broken windows" or else the whole controller neighborhood  
> will start seeping tiny facets of business logic. :)

Hmm, after hearing both sides of the argument, I'm inclined to keep  
writing controller specs, but to gloss over them in their basic CRUD  
form.  They add so little value initially, they are a terrible  
pedagogical example.  Models are much more fun anyway :)

Pat's breakdown,

> * Controllers are already exercised by cucumber
> * Most of the logic is provided by the framework.
> * Controllers tend to be procedural instead of OO

is useful.  The last two make me think that the controller code you  
write should really look like:

   class Items < Application

     # ...

     def show
       Show.new(self, content_type, params).render

     # ...

     class Show
       def initalize(controller, content_type, params)
         @controller = controller
         @content_type = content_type
         @id = id

       def render
         @item = Item.get(params[:id])
         raise NotFound unless @item
         controller.display @item


Forgive the unrunnable botched code example :)

Has issues with assigning instance variables to the controller, and  
not sure what you'd do about the content type (but you could handle it  
in a much more OO way.  In fact, if the controller strategy was  
changed, you could have the show method just return a class:

     def show

or even do it by convention (look for Items::Show).

This way, you get an isolated bit of code you can spec, without  
worrying about all the magic that gets bundled in.

Hmmm, anyway, should get back to writing real code... but I'm going to  
keep this at the back of my mind.

So anyway, controller specs it is, just de-emphasised when I'm  
teaching BDD.

Thanks people.

> Oh, and to an earlier point in this thread.. I can't remember the  
> last time I wrote a view spec.  Any semi-interesting logic that for  
> some reason needs to be in the view I will place in a helper and  
> then spec that out.


I found a long time ago they don't add enough value to justify the  
effort in maintaining them.  Most of the things you write view specs  
for aren't likely to break due to human error, but are often need  
changing due to inconsequential HTML changes.



More information about the rspec-users mailing list