However, you probably don't want to do this. The type of testing most people do is along the lines of fetching a page and running a regex against the returnded HTML to check for correctness. There's no need to use Netscape or IE for this, since Perl is perfectly capable of doing it.

There are dozens of modules for automated web testing on CPAN. You might look at webchatpp, HTTP::WebTest, or HTTP::MonkeyWrench. Lots of others have been announced on the mod_perl list, but I can't remember all of their names now.

Yeah, I'm afraid for now the mandated solution is to perform all actions through a session of Netscape. I've suggested just parsing the HTML with the various Perl mods out there, and we do that to an extent when testing the actual application, but this task involves specifically testing how things are rendered on the Major Browsers.

It's the same problem as if we were writing a Java client that called an API. We'd want a way to test that Java client, both through the GUI and through the API directly.

In our case, however, the browser IS the GUI, and given that, we need to do more than parse the HTML according to how the Perl mods do it, we need to make sure IE and Netscape parse it the way we think they do.

I'm definitely going to look into OLE to work with Netscape. I wasn't sure it could be used since I saw no direct mention of it here or at CPAN. Ultimately I hope it does just come down to parsing the HTML using the standard Perl modules, but in the meantime I gotta do what the boss says. In any event, I don't think rolling my own regexen are the way to go when parsing HTML.

Update: added 'rolling my own' after perrin's most astute comments

thanks!! MM

In any event, I don't think regexen are the way to go when parsing HTML

Most of the HTML parsing modules for perl actually do use regexes. However, what I meant was a regex for checking correctness of content, as in /Hello $username/ or /order number: $order_id/.

For checking NS renders, I dont see how automating would really help, as you have have a human there to make a subjective decision. Surely automating it would take longer than the QA dept trawling thru' a few web screens (depending on the size of the app).

If your html engine is centralised (ie all the html code gen passes thru' the one spot), I would be inclinded to take a sample of perhaps 10 different web pages (or a significant sample) and verify those.

You can then present your UAT doc to mgmt. If mgmt are particularly anal about these things, I reckon including a disclaimer such as "All HTML is produced via a centralised HTML engine."

If you have a large site, you'll be getting into the land diminishing returns which is obviously just not efficient.

I personally think you would be after a process template, rather than automating a point and click solution. With the process template, you'd have a bit of doco that has all the tests you require, all you have to do is perform the tests on "the next platform" and put the results in your document (word templates work well for me).

...
for ( how ever long ) {
     @links = getlinks( $theWebPage );

     foreach $link (@link) {
         system( netscape, $link );
     }
}
...
[download]