Selenium IDE and Ruby/Rails

I am working on a Ruby on Rails application called UnPtnt with Dave Rauchwerk.  The app was not  built using BDD (behavior driven design) and so I am in the process of adding testing after the fact.  I have been learning RSpec, but that tool seems to have much greater utility when used during the design instead of after the app is built.

To get some test coverage quickly I have turned to the Selenium IDE add-on for Firefox.   This is an open source tool that is used to test user interface interactions.  It is part of the larger OpenQA suite of tools.

As usual I have suffered from a learning curve and the process would have gone better if I had known then what I know now.  So I thought I would provide some tips I had to learn the hard way.  They are in no particular order.

Dataset. It is important to have a rich set of data that you use for all tests.  I did this by using the application to put in some data and then saving a backup of the MySQL database.  I restore this backup before running the test suites.

Suites. Of course many of the tests create additional data, so it is important to put the tests into suites in the correct order so that later tests depend on the data created in earlier tests.

Click and AJAX. There are two versions of the click action: one which waits for a page load to complete and one that does not.  Capturing actions with automatic recording does not always get you the one you wanted.  And another issue is that on AJAX calls you need to wait for the server interaction to be complete before proceding, but there is no page load.  Follow these rules.  (1) if the link is a non-AJAX link, it should use clickAndWait.  (2) If it is an AJAX call, it should use click.  (3) For an AJAX call, after the Click, include an action that waits for some event. I usually use the waitForValue action that waits for some value returned by the AJAX call.  You can also use waitForElementPresent or waitForElementNotPresent if you AJAX adds or removes an element.

Click Specificity and XPATH. When automatically recording I find the system records clicks in the least specific way.  For example if you have two links on a page that have the same text, say “edit”, it will record either click as a click on the link with text \”edit\” (click link=edit) which will always click the first edit link even when you mean to use the second.  You can override this behavior by specifying the target of the click to be an XPATH expression.  It is real easy to get the correct expression for any element on your page using a Firefox plugin called XPather.  You can also use a DOM expression, but I find using XPATH easier.

Assert versus Verify. Many commands come in these two flavors.  The difference is that the assert flavor will stop the test if it  fails where verify only loggs the error.  The assert versions do not show up on the context menu, so I use the context menu to add a verify command, and then manually change it to assert if desired.  I tend to put asserts in places where you clearly cannot continue, like checking that a link exists before clicking it.

Batch Testing. Selenium IDE can also create Ruby files that will run the tests in the background.  I have not tried that yet, but if I do I will report on progress.  An alternative to the Selenium IDE Firefox add-on is Molybdenum, which the author claims it is like Selenium but without the ability to create Ruby files.  I have not tried it.