This post originated from an RSS feed registered with .NET Buzz
by Roy Osherove.
Original Post: Web GUI unit testing techniques
Feed Title: ISerializable
Feed URL: http://www.asp.net/err404.htm?aspxerrorpath=/rosherove/Rss.aspx
Feed Description: Roy Osherove's persistent thoughts
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.