Forum: RSpec Celerity and Webrat (using them together, Benchmarks, same API?)

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.
Joaquin Rivera P. (Guest)
on 2009-02-15 14:12
(Received via mailing list)
hey there,
I've been using Cucumber + Webrat for a while. The time has come to spec
Js
and Ajax, so I've been playing around with celerity features (with
culerity
until now).

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

I found usefull to translate webrat steps painless with:
# step with typical webrat API
When /I follow link (.+)/ do |link|
   visits path_to(link)
end

# turn it into this, in steps/common_celerity.rb
When /I follow link (.+)/ do |link|
   visits path_to(link)
end

# trying to retain a single API Webrat-like when using Celerity
def visits(link)
     @browser.goto(link)
end

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?

actually $ top shows some defunkt java processes but dont know whos
responsible culerity, celerity, jruby or my bad installation :-)

3. Is it posible (I know it is CodeCowboy) to use them both together in
same
feature run and say something like:

# in some feature file been able to say cucumber to  use only webrat
:webrat => true
Scenario running this step with webrat should save my time
Given ...

would that be doing the feature "too low level" at the eyes of the
client?
(should the :webrat => true part be moved to some other place?)

if the living together webrat and celerity would pass as valid, then my
latter implementation of the steps in point 1 (and every step run I
guess)
would have to make cucumber recognize which of the Webrat::visits or
Celerity::visits (or any other) is to be called

what do you think? does that make sense? I'll come back with more
later...

cheers,
joaquin
Ben M. (Guest)
on 2009-02-15 19:36
(Received via mailing list)
Joaquin Rivera P. 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/1543bc64ecf850...

> 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
Joaquin Rivera P. (Guest)
on 2009-02-15 20:45
(Received via mailing list)
hey Ben,
thanks for your answers,
I'll give kamal work a try and have a look at the points you are
pointing
about webrat.
I've been playing with culerity for two days and it does not sound
difficult
to accomplish this we are talking.

But I was talking from the culerity part (haven't look too much into
webrat). I have already started to bring together the common_celerity.rb
steps that culerity provides with the by webrat provided common steps,
in
the end by redefining webrat methods (like visit, etc) I can manage to
retain common steps, but still there's to do. I'll have a closer look to
your points and see. Check out here what I have now:
http://github.com/joahking/culerity/tree/webrat_api

at the moment for cucumber to use culerity to run the steps, I just
comment
the webrat initialization in env.rb. But the format.yml is indeed a
place to
look,

more on that later,

cheers,
joaquin
This topic is locked and can not be replied to.