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

Matt Wynne matt at mattwynne.net
Sun Oct 26 17:09:39 EDT 2008

On 26 Oct 2008, at 10:39, Ashley Moran wrote:
> 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 :)

I don't know. I've got inheritance in my controllers, for example I  
have a MediaController which is subclassed by ImagesController and  
VideosController. The specs allowed me to factor out this base class.

I think controllers are OK for doing BDD:

describe "the show action"
	describe "when the video is for an artist"
		describe "when the video cannot be found"
		describe "when the video exists in the database"
	describe "when the video is for a concert"


TBH, I have only just begun to glimpse the idea that cucumber might  
mean I don't need to get 100% coverage from unit-level specs... so I  
may just need more time to get my head around the idea.

I guess it also depends on the rest of your team: it sounds as though  
David can trust the rest of his team to write well designed code -  
it's just him! Personally I feel I need to set the rest of my team a  
good example while they get through the 'shu' stage. Pat - are you  
going solo too?


More information about the rspec-users mailing list