Joaquin Rivera Padron wrote:

1. How usefull would be to have a common API between Webrat and Celerity?

Very useful! In fact someone (Kamal) has already started doing that. Check out his work on his webrat fork:
http://github.com/kamal/webrat/tree/1543bc64ecf85054f9a033e1fc7670806886b41e/lib/webrat/celerity

2. benchmarking webrat vs celerity and any other.

Also have notice that culerity goes slower than webrat, are there any benchmarks about it? (I'll try to put up some of those later) are you noticing this also? or is it just me?
JRuby and HTMLUnit are going to add some overhead, that is for sure. Additionally, they are having to make real HTTP requests to a server, where as with webrat's rails mode it uses rail's integration session and is a lot more lightweight. I would stick to using the :rails mode in webrat for as much as you can and then switch to Celerity for the parts that need JS,



3. Is it posible (I know it is CodeCowboy) to use them both together in same feature run and say something like:
Yes. If you want to run them on the feature, and you can make it work with your step definitions then webrat provides two helpful methods for you to do this:

When /^I do this and that$/ do
 webrat.simulate do
    visit some_path
    # do other non-js stuff
 end
 webrat.automate do
   click_link "Some JS link"
   # do other JS related things
 end
end

So webrat#simulate is only executed in webrat modes that are "simulating" a web browser and have no JS-capabilities. When you are automating a browser, like with the Selenium mode in webrat, the webrat#automate block is ran but not the webrat#simulate. I can't tell if Kamal has added these to his Celerity session but it would fall into the case of #automate (even though it is simulating.. but the fact that it is executing JS is the distinguishing part.)

For some features you may only want them to run with a JS solution. In that case I would recommend using Cucumber's new tagging feature (only available in the latest git version) and tag your features that need JS. You can then create some cucumber profiles in cucumber.yml to only run your JS and non-JS features independently of one another.

As you can tell, a lot of this stuff is very new. But what you described is the end goal and give it a month or two and it will be ready for easy consumption IMO. As it is now, you may need to help iron out some problems with the Celerity webrat session. The big advantage of sticking to the webrat API though is that you can easily swap out the different adapters (i.e. selenium) and run your features without modifying your step definitions.

HTH,
Ben
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Reply via email to