[rspec-users] Merb

[Ben Mabey]

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