Ashley Moran wrote:
On Oct 19, 2008, at 10:31 pm, Caius Durling wrote:
Funny you should post this, I picked up merb today as well (seeing as
the API is finally frozen) and was thinking about posting to see if
anyone else was.
Well, I've done a bit more research (asking around on the Merb list),
and it seems the best practice* in Merbland is to use controller specs
in much the same way as Rails integration tests[1]. While I see the
point that you should test behaviour not implementation, I think that
goes a *little* too far. In short, it's not recommended to do the
equivalent of:
it "should create a new, unsaved person on GET to create" do
Person.should_receive(:new).and_return(@person)
get 'create'
end
There is an API for this though[2], and it was deprecated as of RC1,
but has now apparently been reintroduced.
Lawrence Pit on the merb list explains the syntax:
# ==== Example
# dispatch_to(MyController, :create, :name => 'Homer' ) do
|controller|
# controller.stub!(:current_user).and_return(@user)
# end
And I assume it works similarly with the #get, #post etc. (I have yet
to try it though, and I can't visualise a clean way to write specs
with it.)
Anyway the whole discussion provoked me to crystallise my thoughts on
Ruby web BDD, which I decided to blog[3], and I thought it may be of
interest to people here, in case there's yet a third "right way" of
doing things.
(If anyone finds this of interest, let me know. If so, I might start
an "Adventures in Merb BDD" series - or something - on my blog.)
Ashley
* I've padded up in anticipation of the chair I know Aslak will hurl
when he reads that ;o)
[1] http://www.slideshare.net/wycats/testing-merb-presentation
[2]
http://merbivore.com/documentation/0.9.9/doc/rdoc/merb-core/index.html?a=C00000147&name=RequestHelper
[3]
http://aviewfromafar.net/2008/10/20/web-app-bdd-thoughts-as-i-move-to-merb
Yeah... In regards to the controller specs... I wouldn't call that 'best
practice' or 'the' right way. I would call that wycats's way of testing
and how most of the merb community has decided to follow suite. I'm not
saying a purely mock-based approach is 'best practices' either- they are
both good practices and infinitively better than the alternative of
having no tests at all!
That being said, I'm a big proponent of outside-in development which is
largely made possible by being able to spec out your interface with
mocks *before* it exists. We had a good discussion on the tradeoffs of
using mocks on this list recently. Here is a message from that thread,
by Zach Dennis, in which he explains outside-in development very well:
http://rubyforge.org/pipermail/rspec-users/2008-September/008426.html
It seems like the merb community places more emphasis on application
wide tests- which is good since that is all the customer will really
care about in the end. Application wide tests are great (and that is
why we have cucumber) but I wouldn't forgoe having a fast object level
suite. Without a lightning fast suite the refactoring process will be
drawn out and tracking down breaks can be harder without the focused
object examples. That has been my experience at least and so that is
why I like to have application level features which touch the entire
stack and then have faster and more focussed object level specs that
rely on mocking.
Like I said, that is how I like to development my apps and not 'the'
right way to do it.
Anyways, thanks for sharing your findings.
-Ben
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
