Merb

Testing RSpec
1

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/merb-core/test/test_ext/rspec.rb

–
http://www.patchspace.co.uk/

2

On Sun, Oct 19, 2008 at 2:36 PM, Ashley M.
[email protected] 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

3

On Oct 19, 2008, at 9:43 pm, David C. 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/

4

On Sun, Oct 19, 2008 at 4:11 PM, Ashley M.
[email protected] 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.

5

Caius D. 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:

-Ben

6

On 19 Oct 2008, at 20:36, Ashley M. 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 D.
[email protected]
+44 (0) 7960 268 100
http://caius.name/

7

On Oct 19, 2008, at 10:31 pm, Caius D. 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! :smiley:

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/

8

On Oct 19, 2008, at 10:31 pm, Caius D. 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 P. 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] Testing Merb
[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

–
http://www.patchspace.co.uk/

9

On Oct 20, 2008, at 9:22 pm, Ben M. 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 D., in which he explains outside-in
development very well:
http://rubyforge.org/pipermail/rspec-users/2008-September/008426.html

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/

10

On 20.10.2008, at 22.05, Ashley M. wrote:

There is an API for this though[2], and it was deprecated as of RC1,
but has now apparently been reintroduced.

Lawrence P. 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 L.

http://odesign.fi

Check out my latest book, Unobtrusive Prototype, fresh off the
Peepcode oven:
http://peepcode.com/products/unobtrusive-prototype-js

11

On Oct 21, 2008, at 7:24 am, Jarkko L. 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 :slight_smile:

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/

12

Ashley M. wrote:

point that you should test behaviour not implementation, I think that

with it.)

[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 D., 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