Re: [rspec-users] Merb
On Oct 21, 2008, at 7:24 am, Jarkko Laine wrote: 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. 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/ ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Merb
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 ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Merb
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=C0147name=RequestHelper [3] http://aviewfromafar.net/2008/10/20/web-app-bdd-thoughts-as-i-move-to-merb -- http://www.patchspace.co.uk/ http://aviewfromafar.net/ ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Merb
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=C0147name=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
[rspec-users] Merb
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/
http://aviewfromafar.net/
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Merb
On Oct 19, 2008, at 9:43 pm, David Chelimsky wrote: 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. 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/ ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Merb
On Sun, Oct 19, 2008 at 4:11 PM, Ashley Moran [EMAIL PROTECTED] wrote: On Oct 19, 2008, at 9:43 pm, David Chelimsky wrote: 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. 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?) 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. Ashley -- http://www.patchspace.co.uk/ http://aviewfromafar.net/ ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Merb
Caius Durling wrote: 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? 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 ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Merb
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/ ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
