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
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
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:
> xwininfo -children
xwininfo: Please select the window about which you
would like information by clicking the
mouse in that window.
xwininfo: Window id: 0x4c0000c "test - Opera"
Root window id: 0x82 (the root window) (has no name)
Parent window id: 0x1e044da (has no name)
8 children:
0x4c00028 (has no name): () 1672x27+0+0 +4+52
0x4c00031 (has no name): () 1x1+-1+-1 +3+51
0x4c00030 (has no name): () 862x961+0+28 +4+80
0x4c00012 (has no name): () 100x11+0+0 +4+52
0x4c00011 (has no name): () 1x961+862+28 +866+80
0x4c00010 (has no name): () 1x961+0+28 +4+80
0x4c0000f (has no name): () 862x1+0+989 +4+1041
0x4c0000e (has no name): () 862x1+0+27 +4+79
Now guess which is what.
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.
Yes, but not in the complicated prone-to-fail way you think. Applications shall provide accessibility hooks. http://ldtp.freedesktop.org/ http://en.wikipedia.org/wiki/Microsoft_Active_Accessibility http://www.apple.com/accessibility/macosx/
Drivers such as accessibility aides or in our case testing frameworks then can interpret and manipulate any application elements (widgets, stuff on canvases or rendered areas) directly.
i have a fair chance of being able to implement a pretty interesting version of the WWW::Mechanize
Already done. Save yourself the trouble of re-inventing. http://google.com/search?q=mozrepl http://search.cpan.org/dist/WWW-Mechanize-FireFox
Re: Browser based testing of your own code
daxim on 2009-11-16T14:03:52
> xwininfo -children
I made a mistake there, should have been
-treeinstead of-children. The argument still stands – the descendant windows have neither type nor name.
