At APT, we’ve recently completed a transition to using Selenium’s Java RC1 for our regression testing framework. One of the excellent things about Selenium RC is the ability to add functionality with relative ease.
In this entry, I want to briefly cover how we get around the onLoad() event caveat of Selenium. Since Selenium works by Javascript injection, it is unable to catch onLoad() events, which can prove to be troublesome when dialog boxes are hit onLoad(). Our code base is relatively large for such a small company and in testing we are really pushing the limits of Selenium. Our goal is to have all of our front-end testing done through Selenium, which means that it needs to elegantly handle Javascript errors and onLoad confirmations/alerts.
When executing an action such as click(), Selenium can hang if a Javascript error is hit. In order to handle this, we now spawn a separate thread to handle any action that might alter the state of the page. The main thread is then able to poll and check if the action thread has hung and if it has we call an AutoIt script2 which closes the dialog box and logs an error to our database. This is especially powerful because it lets our tests continue to run with virtually no human interaction.
By leveraging anonymous classes in Java, any Selenium function can quickly be overloaded and run in a custom multithreaded execution thread, as well as make any encountered errors available for the main thread to handle.
This is just an example of how we are automating Selenium, which is crucial in order for it to work with our distributed framework. In my next blog entry I would like to cover how we are accomplishing quick distributed compilation.
- Dan Hackner
1 – http://seleniumhq.org/projects/remote-control/
2 – a Window’s GUI level scripting language. http://www.autoitscript.com/autoit3/
No comments:
Post a Comment