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"
etc.
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?
cheers,
Matt
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
