Forum: RSpec Merb

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
2ce9c0106b5851b2294ba5eb9f5c04bd?d=identicon&s=25 Ashley Moran (Guest)
on 2008-10-19 21:37
(Received via mailing list)
Hi

Two questions:

Anyone using Merb here, and writing specs for it?  (I've just started
tonight, so I'm figuring stuff out as I go along.)

And WDYAT of their spec extensions[1]?  Specifically their "given"

   given "a item exists" do
     request(resource(:items), :method => "POST",
       :params => { :item => {  }})
   end

   describe "resource(:items)" do

     describe "GET", :given => "a item exists" do
       before(:each) do
         @response = request(resource(:items))
       end

       it "has a list of items" do
         pending
         @response.should have_xpath("//ul/li")
       end
     end

   end

Have to say I was a bit surprised to learn they'd monkey-patched
RSpec...

Ashley

[1]
http://github.com/wycats/merb-core/tree/master/lib...


--
http://www.patchspace.co.uk/
http://aviewfromafar.net/
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2008-10-19 22:43
(Received via mailing list)
On Sun, Oct 19, 2008 at 2:36 PM, Ashley Moran
<ashley.moran@patchspace.co.uk> wrote:
>    request(resource(:items), :method => "POST",
>      it "has a list of items" do
>        pending
>        @response.should have_xpath("//ul/li")
>      end
>    end
>
>  end
>
> Have to say I was a bit surprised to learn they'd monkey-patched RSpec...

Well, in fairness to wycats, rspec doesn't really offer formal
extension points that would support this syntax, so he did the best he
could given what is available. We've had some discussion about this
and haven't landed anywhere firm yet.

My opinion is that rspec, as it stands right now, needs a bit of
internal cleanup before we start adding new features like that one.
Also, the way I'd like to see this go is that rspec exposes a formal
extension point - some sort of hook into pre and post-processing of
each example including any arguments it was given. Then the merb
extension could use a published API rather than monkey patching.

FWIW,
David
2ce9c0106b5851b2294ba5eb9f5c04bd?d=identicon&s=25 Ashley Moran (Guest)
on 2008-10-19 23:12
(Received via mailing list)
On Oct 19, 2008, at 9:43 pm, David Chelimsky wrote:

> extension could use a published API rather than monkey patching.
Ah, I understand now.  I didn't mean my comment in a negative way,
just that Merb has a philosophy of simplicity and transparency, and
monkey-patching is the Rails way to do things.  Hence my surprise.
And spec code too... if anything's gonna make me nervous!

Is the Merb spec syntax (or something like it) something you'd like in
the future?  (RSpec 2?)

Ashley

--
http://www.patchspace.co.uk/
http://aviewfromafar.net/
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2008-10-19 23:19
(Received via mailing list)
On Sun, Oct 19, 2008 at 4:11 PM, Ashley Moran
<ashley.moran@patchspace.co.uk> wrote:
>> Also, the way I'd like to see this go is that rspec exposes a formal
> Is the Merb spec syntax (or something like it) something you'd like in the
> future?  (RSpec 2?)

Not sure about that yet. You can already accomplish the same thing
with a variety of existing structures and I think that this structure
brings up other questions like:

* how about a :when and :then?
* how does this impact the output?
* etc

However, I'm definitely interested in developing and committing to an
API that makes it easy to write extensions like this. Then wycats
could publish this as a separate extension gem, for example, and those
who like it can easily use it w/o concern for the fact that it is
monkey patching another library.
5f01846708cd8d474cae677fb20c786e?d=identicon&s=25 Caius Durling (Guest)
on 2008-10-19 23:32
(Received via mailing list)
On 19 Oct 2008, at 20:36, Ashley Moran wrote:

> Anyone using Merb here, and writing specs for it?  (I've just
> started tonight, so I'm figuring stuff out as I go along.)


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.

You attempted to throw cucumber into the mix yet?

C
---
Caius Durling
caius@caius.name
+44 (0) 7960 268 100
http://caius.name/
C694a032be7518a0d704318895f8fe1d?d=identicon&s=25 Ben Mabey (mabes)
on 2008-10-19 23:37
(Received via mailing list)
Caius Durling wrote:
> You attempted to throw cucumber into the mix yet?
I used the told story runner with merb and I had no issues.  I haven't
done any merb apps since cucumber but it looks like there is already a
library to make using Cucumber in merb easy:

http://github.com/david/merb_cucumber/tree/master

-Ben
2ce9c0106b5851b2294ba5eb9f5c04bd?d=identicon&s=25 Ashley Moran (Guest)
on 2008-10-20 01:05
(Received via mailing list)
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.
>
> You attempted to throw cucumber into the mix yet?


Of course!  :D

However, I'm using hand-rolled Celerity-based stuff, rather than the
Webrat stuff in the generator.  So there's nothing merby about my
cucumber files (well, file, right now), but then I like restricting
Cucumber to talk over HTTP.

I've been taking notes, and hope to blog about the experience in the
next week or two.

Ashley


--
http://www.patchspace.co.uk/
http://aviewfromafar.net/
2ce9c0106b5851b2294ba5eb9f5c04bd?d=identicon&s=25 Ashley Moran (Guest)
on 2008-10-20 21:09
(Received via mailing list)
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/...
[3]
http://aviewfromafar.net/2008/10/20/web-app-bdd-th...


--
http://www.patchspace.co.uk/
http://aviewfromafar.net/
C694a032be7518a0d704318895f8fe1d?d=identicon&s=25 Ben Mabey (mabes)
on 2008-10-20 22:25
(Received via mailing list)
Ashley Moran wrote:
> point that you should test behaviour not implementation, I think that
>
> with it.)
>
> [3]
> http://aviewfromafar.net/2008/10/20/web-app-bdd-th...
>
>
>
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-Se...

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
2ce9c0106b5851b2294ba5eb9f5c04bd?d=identicon&s=25 Ashley Moran (Guest)
on 2008-10-20 23:44
(Received via mailing list)
On Oct 20, 2008, at 9:22 pm, Ben Mabey wrote:

> 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-Se...

Hi Ben

That's a great post by Zach, thanks for the link to it.  Zach - if
you're reading this - please blog it.  I've had to delicious the
RubyForge page.


> 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)

I agree, which is why I find it odd that the Merb community is using
RSpec to do Cucumber's (or the classic Story Runner's) job.


> 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.

Exactly how I work, and (I imagine) the way most people here work.
Not that that makes it right, of course.  But I find it invaluable to
have pure interaction-level spec, or one that wraps behaviour where
the output is more important than the interactions (eg parsing XML, in
my experience).


> Anyways, thanks for sharing your findings.


My quest for enlightenment continues...

Ashley


--
http://www.patchspace.co.uk/
http://aviewfromafar.net/
82476266af9d460415d8f1fc16bb54ed?d=identicon&s=25 Jarkko Laine (jarkko)
on 2008-10-21 08:25
(Received via mailing list)
On 20.10.2008, at 22.05, Ashley Moran wrote:
> 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

Yeah, I was using that API to a great extent with a recent project and
was pretty successful at doing outside-in development with rspec and
merb. The syntax used in merb controller specs is a bit different from
what Rails uses, but once you got around it, it was actually pretty
cool and flexible. Here's a snippet from a controller spec in the
project:

http://pastie.org/private/6uijgfwwzjngvhbkgxwqq

Note that I generally stub both render and display for the controller
to make the tests run faster.

There's probably a lot of optimization left to do with the specs but I
find the dispatch helpers pretty cool for building more specialized
methods such as do_post.

I hope the merb folks will keep us outside-(s)inners in mind and not
scrap the API.

Cheers,
//jarkko

--
Jarkko Laine
http://jlaine.net
http://dotherightthing.com
http://odesign.fi

Check out my latest book, Unobtrusive Prototype, fresh off the
Peepcode oven:
http://peepcode.com/products/unobtrusive-prototype-js
2ce9c0106b5851b2294ba5eb9f5c04bd?d=identicon&s=25 Ashley Moran (Guest)
on 2008-10-22 22:29
(Received via mailing list)
On Oct 21, 2008, at 7:24 am, Jarkko Laine wrote:

> controller to make the tests run faster.
>
> There's probably a lot of optimization left to do with the specs but
> I find the dispatch helpers pretty cool for building more
> specialized methods such as do_post.

Hi Jarkko

Thanks a lot for that.  I've just got my first controller spec
working, that's a big win!

How do you handle #only_provides ?  The merb format handler is way
slicker than respond_to, but I can't get a handle on how to spec its
behaviour.  (Should you fake an XML request for controllers with
"only_provides :html", or is
controller.should_receive(:only_provides).with(:html) more appropriate?)

And actually:

   it "should display a new Item" do
     do_get do |controller|
       controller.should_receive(:display).with(@item)
     end
   end

is really nice syntax.  Just need to work on factoring out the helper:

   def do_get(&blk)
     dispatch_to(Items, :new) do |controller|
         controller.stub!(:render)
         controller.stub!(:display)
         yield controller if block_given?
     end
   end

from specs, but you can't abstract one file!

In this case, RSpec mocks are simpler than not_a_mock.  (More reason
to be able to switch framework at runtime?)


> I hope the merb folks will keep us outside-(s)inners in mind and not
> scrap the API.

I notice you're on both list so hopefully you can give me nudges in
the right Merb direction and Merb nudges in the right BDD direction :)

But I also hope they will make concessions to isolated controller
fans.  All the more reason for me to write up what I find, I guess.

Cheers
Ashley


--
http://www.patchspace.co.uk/
http://aviewfromafar.net/
This topic is locked and can not be replied to.