Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ddick (5726)

ddick
  (email not shown publicly)

I'm based out of Melbourne, Australia. I attend the excellent melbourne.pm.org meetings whenever i get the chance, which is not often enough.

Journal of ddick (5726)

Monday November 16, 2009
05:38 AM

Browser based testing of your own code

[ #39902 ]

For those of us engaged in developing/supporting a web application, testing seems to be an almighty pain.

The state of the art seems to be; put a massive investment into writing test cases in Tool X, which manages (sort of) Browser Y. However thanks mainly to mozilla and khtml, but really opera and explorer are just as capable here, we can never be really sure if someone isn't going to come up with a great new browser.

The moment someone comes out with a new product, the whole testing routine needs to be re-written, usually, completely from scratch. B/c i haven't seen a tool that automates konqueror, opera, explorer and mozilla. Certainly not for linux as well as windows. However, i think this should be possible.

First things first, the automation script should be able to start up the browser and control it. X11::GUITest and Win32::GuiTest provides the basics of being able to recognise a window and send keystrokes and mouse clicks to it, which should be enough.

Secondly, the automation program must be able to recognise the correct page to the page to send input to, by clicking the mouse or tabbing.

This is where each new browser needs to provide some initialisation data. By using HTTP::Daemon, some sort of ajax mechanism, the onfocus and onclick events and X11::GUITest/Win32::GuiTest, it should be possible to recognise how many tab presses to get the first form field on the page AND the exact offset to allow you to put the mouse over any desired element. Calculating each elements position can be achieved using offsetLeft, offsetTop and offsetParet, which i think are universally supported now.

Once this is done, we can take load the web application for testing into some incarnation of HTTP::Daemon, together with our testing code and launch the browser to point at the daemon.

Apologies to those frame haters out there but i think the testing code needs to create a couple of frames, one containing the web application and one containing the requests/responses from the testing code. b/c all the requests are coming from the same source (the HTTP::Daemon) as the web application, it should be possible to launch cross frame queries to interrogate the web application window for the position of say the "Submit" button or the "Description" text box, allowing the test code to then move the mouse over it and click it, or just to press tab the correct number of times.

Getting at the source of the current web application page can be done by interrogating the HTTP::Daemon for the page source.

At this point i think i have a fair chance of being able to implement a pretty interesting version of the WWW::Mechanize interface, but testing the css and javascript for all known or future browsers.

However, getting the time to do it might be a bit tough at the moment

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • i haven't seen a tool that automates konqueror, opera, explorer and mozilla.

    The heyday of Konqueror is over. Wouldn't you rather test with Webkit based browsers? http://seleniumhq.org/docs/01_introducing_selenium.html#supported-browsers [seleniumhq.org]

    X11::GUITest [...] provides the basics of being able to recognise a window and send keystrokes and mouse clicks to it, which should be enough.

    That's not enough at all. Dump of an Opera 10 application window that has loaded one document with a complex HTML form:

    > xwinin

    • > xwininfo -children

      I made a mistake there, should have been -tree instead of -children. The argument still stands – the descendant windows have neither type nor name.