If Bryan wraps the webrat API around the Watir API, it can also be
used against the new kid on the block: http://celerity.rubyforge.org,
which implements the Watir API backed by JRuby and HTMLUnit - orders
of magnitudes faster than Watir - and agnostic of webapp architecture
(http based). This means webrat could be used against e.g. Java webapps.
I'm planning on adding native webrat support to Cucumber (on Github)
and you can see it in action in Ba (on Gitorious).
Aslak.
Sent from my iPhone
On 9. juni. 2008, at 20.11, Ben Mabey <[EMAIL PROTECTED]> wrote:
Joseph Wilk wrote:
Create two classes (this is already what MHS_testing has done for
Selenium)
----
class RailsSeleniumStory < RailsStory
class RailsWebratStory < RailsStory
----
Create a common interface for all shared functionailty.
(I suspect Webrat represents the smallest set of functionality -
Selenium can do everything Webrat can do but not the other way
around).
The different UI testing frameworks implement such interface giving
Selenium/Webrat/Other UI adapters.
You choose which adapter to use by the story class.
...
I'm not sure what direction MHS_testing or Rspec-ui are going,
whether
they will merge? I'm looking at this problem now and want to start
contributing to whatever project is going to be the best fit. So I'm
interested to hear:
*Feedback/discussion about this direction
*Any better ideas of solving the problem
*Any other frameworks out there were people have started to look at
this
problem.
--
Joseph Wilk
http://www.joesniff.co.uk
Hey Joseph,
Have you looked at webrat in github lately?
http://github.com/brynary/webrat/tree/master
Bryan is abstracting webrat so that different adapters can be
plugged into it.. Meaning, the same wrappers/syntax can be used to
drive rails, merb, mechanize, etc... I think a selenium or watir
adapter for webrat would be awesome. I'm not too experienced with
selenium but it doesn't strike me as being too hard to do. You make
a good point in that webrat is a small subset of what the other JS
aware frameworks can do but I think what webrat currently has would
handle a lot of the use cases. One could then perhaps create an
extension of webrat's language to form a uniform way of expressing
JS/AJAX behaviour.
The mechanize adapter idea is neat too, because you could then use
it to test any website no matter what the implementation is. I know
that part of Bryan's motivation behind the mechanize spike is to
eventually use the stories to do performance testing as well.
This is a problem I'm also interested in but I haven't yet needed to
use selenium enough to make me want to do anything about it. :) I
think the selenuim adapter for webrat approach would be a great way
to approach this problem though. What do you think?
-Ben
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
