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
end
# ...
class Show
def initalize(controller, content_type, params)
@controller = controller
@content_type = content_type
@id = id
end
def render
@item = Item.get(params[:id])
raise NotFound unless @item
controller.display @item
end
end
end
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
Show
end
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.
+1
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.
Cheers
Ashley
--
http://www.patchspace.co.uk/
http://aviewfromafar.net/
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
