I have used The Mech and I understand HTTP::Recorder

I have also examined in a cursory fashion Canoo Webtest, HTTPUnit, and other such tools.

But they don't handle client-side scripting.

I have been intrigued by IEUnit and Selenium, but I am wary of JavaScript and cross-site scripting problems.

And I want to be able to talk to the filesystem, the network, and the database also.

And I have investigated SAMIE, but the lack of documentation has stopped me cold, as have some of the implementation details.

Last week I attended The Austin Workshop on Test Automation where I demonstrated HTTP::Recorder and met with a number of wizardly folk who are using the Web Application Testing In Ruby (WATIR) framework. I saw amazing things done in very few lines of Ruby.

In my opinion, WATIR has no peer as a framework to drive functional test automation in Internet Explorer.

In a nutshell: driving functional testing in Internet Explorer with WATIR and Ruby, while putting a WWW::Mechanize-based analyzer inside of HTTP::Proxy (a la HTTP::Recorder), is a freakishly powerful environment for functional testing and performance testing.

Look to hear more about WATIR in the future. Unfortunately, it's not Perl, so that news won't be here-- but I suggest anyone interested in functional testing using IE as an interface check out WATIR.
  • Comment on Testing at the browser: a trip report. (Perl, Ruby, etc.)

Replies are listed 'Best First'.
Re: Testing at the browser: a trip report. (Perl, Ruby, etc.)
by Arunbear (Prior) on Jan 12, 2005 at 09:58 UTC
    Have you not heard of Win32::IE::Mechanize? It seems to do everything that WATIR does, and you could always submit a patch if it lacks a feature you think it should have but doesn't.
[reply]
Re: Testing at the browser: a trip report. (Perl, Ruby, etc.)
by eyepopslikeamosquito (Archbishop) on Jan 12, 2005 at 04:51 UTC
    Look to hear more about WATIR in the future. Unfortunately, it's not Perl, so that news won't be here-- but I suggest anyone interested in functional testing using IE as an interface check out WATIR.

    How hard would it be to implement WATIR in Perl, based on Win32::OLE, say? Is there any intrinsic reason why Ruby is better suited to this task than Perl?

[reply]
      The critical techology in WATIR isn't the language in which it is written. The critical technology is the sophistication with which the framework is capable of manipulating the Document Object Model (DOM) in Internet Explorer.

      The WATIR people are doing an outstanding and elegant job of this in Ruby. There's no reason it couldn't be done in Perl, but no one has yet, at least at the level of elegance and sophistication demonstrated by WATIR.
[reply]
        The WATIR people are doing an outstanding and elegant job of this in Ruby. There's no reason it couldn't be done in Perl, but no one has yet, at least at the level of elegance and sophistication demonstrated by WATIR.

        Well, there is SAMIE and Win32::IE::Mechanize.

        Personally, I'm not as certain as you are that Ruby isn't a critical part of WATIR's success. From what I have seen people find it much easier to move from WAITIR to more general Ruby code than from Perl testing frameworks to more general Perl programming.

        Much as I love Perl it's been my experience that people find learning Ruby easier.

[reply]
        TRUE. I would like to have Win32:Watir :-))
[reply]
Re: Testing at the browser: a trip report. (Perl, Ruby, etc.)
by perrin (Chancellor) on Jan 12, 2005 at 15:40 UTC
    What is it about client-side scripting that you want to test? You can already test any server-side code with HTTP::Recorder, including code that is called by JavaScript on the client, because the full HTTP interaction is captured. The only thing that you can't test with it is your JavaScript itself.
[reply]
      I agree. But (for instance), I have an application that uses ActiveX and Javascript to implement custom RPCs between IE and the server. No HTTP involved. The whole application is invisible to HTTP::Recorder.

      And when the JS is a couple of frames deep in the page, poking at it becomes troublesome.
[reply]
Re: Testing at the browser: a trip report. (Perl, Ruby, etc.)
by Anonymous Monk on Jan 12, 2005 at 20:43 UTC
    This message indicates that IeUnit doesn't allow test scripts to access filesystem, network, etc. This is not correct. IeUnit, unlike Seleunium, is not hosted by the IE browser. IeUnit test scripts can access all system resource exposed through OLE objects, just like WATIR or IE::Mechanize do.
[reply]
Re: Testing at the browser: a trip report. (Perl, Ruby, etc.)
by henrywasserman (Initiate) on Jan 28, 2005 at 17:18 UTC
    samie's slingshot is a nice gui tool that helps you write samie scripts
[reply]
      Here's a nice demo movie of slingshot.
[reply]

Back to Meditations