ben at benmabey.com
Mon Oct 20 16:22:09 EDT 2008
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. 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
> get 'create'
> There is an API for this though, 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.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, 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.)
> * I've padded up in anticipation of the chair I know Aslak will hurl
> when he reads that ;o)
>  http://www.slideshare.net/wycats/testing-merb-presentation
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:
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.
More information about the rspec-users