Selenium @ CIT

The first time I was presented Selenium I had the wrong understanding of it.

Few months ago, a group of client side developers organized a talk in our department about testing javascript code. The focus was mainly on jsUnit, but it was also the first time I heard of Selenium. It was presented as an alternative to jsUnit to test client side javascript in a cross-browser way.
For that purpose Selenium acts as a browser plugin that allows one to record his actions on the browser on a particular site and play them back later.
You can also finetune the generated scripts.

In the same time I was starting to think about acceptance testing and automation testing.

Until the Continuous Integration and Testing conference in London, I didn't realise there was a link between the two.

During that Open Space conference, there was a talk by a guy from Germany.
He was sharing his experience with Selenium for acceptance testing.
Obviously the product he was developing is a web application.
It means that most of features (or business value) are accessible from a web GUI.

This how it became really clear to me that Selenium can work in two way: in addition of the plugin mode for manual record/playback, there's a driven mode that allow a programmatic control of Selenium. Now we are getting closer to automation :-)

Before going that way, I'll dwell a bit more on the acceptance testing part of it.
The acceptance tests are the tests that prove the product owner/customer that the software is doing what he has specified. For a web applications, most of the business features are visible on a web interface. Even if for some reasons the business value is invisible (backend features of some sort) it's often possible to make it exposed on a web interface:

• On an earlier project one of the requirement was that the system should process data within a ceration amount of time. We build a small web application to expose the cycle duration on a web interface. We used Nagios to monitor this value but we could easily imagine that this information can also be captured for acceptance tests.

• Let's say that you've been asked to syndicate your data as RSS feeds. You can use Firefox as an RSS aggregator and test the feeds from there.

• On another project the feature was to import a continuing feed of complex XML documents in a database. The team setup a smart logging and exposed import successes and failure on a web interface.

Now, we can go back to automation.
Selenium can be driven programmatically through a number of platform (java, python, ruby and perl). It uses a component called Selenium Remote Control which is a java server that run on the same platform where a web browser is available.

There's also a platform dependent API that sensd command to the Remote control using the language of choice.

In perl you can use a CPAN module called Test::WWW::Selenium.

The whole thing becomes really interesting when you combine that approach with the use of FIT (Framework for Integration Testing, which is more than a framework actually), but that's another story.