Automated Testing

1 04 2009

Hey there

Lately, I’ve been looking at automated testing. I went through a whole gaggle of tools, mostly FOS (Free/Open Source). Automated testing has been something that interested me for a while.

The project I’m currently working on involves an AJAX web app written in .NET 3.5. As such, I’ve had to contend with the difficulties of background activity after the page has loaded. Today, I want to share with you some of the lessons I’ve learned.

Firstly, you should know I’ve been working a lot on a tool called Selenium IDE. It’s a plugin for FireFox and is free and open source. You can take a look at it here if you’d like.

Hunting Wascally Controls

AJAX introduces a whole new fun. When your page loads, depending on the control, it will be displayed and available immediately or later as things are downloaded and executed in the background. Other times, it may be that a control is unhidden because of a user-selection, or because of some other event. In general, the page loading has no immediate bairing on the availability and visibility of controls! Yay!

Don’t get depressed. Selenium has many commands. Where a command acts on a control, there is likely a “waitFor” command available as well. So, for instance, if I trigger an event, I can “waitForElementPresent” before I inspect it, or “waitForTextPresent”. These commands are specifically intended for an AJAX web app.

Held Up In Traffic

Often, AJAX web apps download so many things in the background, executing scripts and so forth, that the page has not finished loading in the background. Sometimes, this just means a faster user experience not having to wait for things to download but other times it can mean being held up by background traffic.

Selenium often uses the “clickAndWait” command when navigating. This command is generally intended to click, i.e. instigate the navigation, and then wait for the page to load. Selenium, however, is not intending to wait forever and by default will only wait 30 seconds. With the project I’m looking at especially, 30 seconds is no where near enough time. As such, I use the “setTimeout” command to increase the duration that Selenium will wait for; I set it at 5 minutes or 300000 milliseconds when passed to the command. This tells Selenium that things will likely take longer and you get less timeouts.

Starting From The Beginning

Another thing I’ve learned is to always assume the script is not starting in the right place within the application or website. As such, I always have the first few steps navigate back to the beginning or starting point for all scripts. This means I don’t have to worry about where one script ends ready for the next script.

Absolutely!

The last point I’d like to share is to always use an absolute URL for the “open” command. The “open” command simply sends the browser to the correct location to begin testing. By using an absolute URL, it means I can just open a browser window and hit Start. Even if the browser is displaying the Quality in Software blog, the “open” command will take the browser to the right server ready to begin testing.

A Few More Comments

Just to finish, I’d like to make a few comments as to why I like Selenium IDE. Firstly, it is free and open source. There are a lot of arguments both for and against FOS software but the best argument for is that it’s accessible to more people; I like that. The second thing is that it uses a real browser to perform the testing; none of this pretend stuff where it simulates accessing the website or uses its own rendering engine. Although its recording is confined to FireFox, it is possible to execute using all the popular browsers. That makes sense since it means testing the scripting and functionality on the platforms they will be deployed to!

Anyway, I’ll leave it at that. Let me know of your experiences with Selenium or with automated testing in general.

Kind Regards
Glenn