Test::WWW::Selenium::Conversion::IDE

At $work we have a LIMS system running as a web app. Nothing unusual there. However, we had a user experience a bug which had only be seen once before, and seemed impossible to recreate.

It seemed to come from asynchronous Ajax updates to one field on the user session.

My first thought, was how to recreate this bug which only comes up rarely. On my development version, I couldn't get it to happen. So, I decided to have a play with Selenium. After downloading the Firefox plugin, I recorded the actions that our user did, and ran through as fast as it would replay.

Success, the bug reappeared. If run at slow speed, the test ran through happily, but fast caused the issue with the Ajax.

Working on a solution then gave me a test case to work against, and I can happily report that the bug has gone away.

Now, as a reader of this blog, you know I am a Perl programmer, and, yes, this app is just that. A Clearpress app.

We have a good test suite exercising the model, view and api, but we don't have anything UX tests. So, can I run the Selenium IDE file (Selenese HTML) in the Perl test suite. CPAN has two modules providing drivers for the Selenium Server, but no converter from Selenese to Perl Test. That seemed to go some time ago.

So, time to actually do something about it. I chose to use the Test:: WWW::Selenium module over Selenium::Remote::Driver, as I preferred the API.

Now, I had two strategies here.

1) Fully convert the Selenese HTML file to a Perl Test file,
2) On the fly, convert and run the Selenese HTML file

I opted for 2, as I coul just hard code in a wrapper test a Selenese suite file, and then every time we record another user story, it will just get added to the suite, and run. Also, keeping the code DRY, as it will b handy to keep the Selenese HTML around to run individually in the IDE.

So, I started developing Test::WWW::Selenium::Conversion::IDE, to do just that. I released it yesterday to CPAN.

It should most definitely be considered ALPHA code. I am unlikely to change the function names, as $work will rely on it, but it is by no means feature complete. I welcome comments and patches if you need more features.

The way it works:

1) In a wrapper test file, create a Test::WWW::Selenium object with creds for your Selenium Server
2) Pass to the suite runner function this object and the filename of your suite file. You can also pass the location of the file, but it defaults to t/selenium_tests.
3) Rather than give a plan, use done_testing() at the end of your file, so the TAP plan can be accounted.

See POD for more options.

So, I push it out for the communities use.

Bye for now.