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/
On Sun, Oct 19, 2008 at 2:36 PM, Ashley Moran <ashley.moran at patchspace.co.uk> wrote:> 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...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> > 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
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/
On Sun, Oct 19, 2008 at 4:11 PM, Ashley Moran <ashley.moran at patchspace.co.uk> 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
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 at caius.name +44 (0) 7960 268 100 http://caius.name/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20081019/31a527fe/attachment.html>
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
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/
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) > # endAnd 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 -- http://www.patchspace.co.uk/ http://aviewfromafar.net/
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
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-September/008426.htmlHi 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/
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) >> # endYeah, 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
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/