Continuing my Unit testing theme in recent weeks, I've found a very interesting post in reply to a question posted on the XP mailing list. What was so interesting is that the question, and thus the answer, deal with a side of testing that I never though had clear and obvious testing techniques that enabled true unit testing - testing web GUI. I was wrong. The answer also introduces a couple of unit testing framework tools and techniques I never heard of .How fun it is to discover something new everyday!
Question:
> How does one automate test scripts for GUI's ? Like
> logging in to a web application, choosing from a menu,
> keying in data, and retrieving to check if the data is
> valid, and so forth ?
Answer:
Try the TestFirstUserInterfaces mailing list.
One automates tests for those features at three levels:
Test your HTML, before the server sends it. Write XML-compliant HTML, and
use XPath to query out the HTML commands that support your menus and forms.
Use HttpUnit as a "mock browser". It will drive the HTTP protocol, and make
the server think a normal user hits your page. Then write tests that ensure
your page has the controls it says it does.
The third way: Use a scripting language, such as Perl or Ruby, and open
Internet Explorer as a COM server. Drive it to navigate to your page and
download it. Then exploit the same Document Object Model as JavaScript
bunnies use, to inspect the controls as objects, and to click on them.
As usual for much of XP, you can get very far testing as close as possible
to the tested code. Most of the time, prefer the first way. But only the
third way "proves" your Web page does the right thing when clicked.
GUI testing exposes a raft of weird situations. XPath is the best way (I
have found) to test HTML. But most HTML is not XML compliant, under the
naive assumption that permitting programmers to write sloppy HTML will speed
them up. Much attitude readjustments are needed here.