Posted on

Simple Web App Testing

After all the discussions about testing web apps and working with a variety of relatively horrible app testing platforms, I have been learning Selenium IDE.  Selenium IDE is the “little brother” of the full blown Selenium Web Driver.    Where Web Driver is a robust client/server framework with distributed testing and full test logic options, IDE is a simple light weight scripting plugin for your browser.

 That is what I like about IDE.   I know what it is and don’t push it beyond those limits.  It is basically a “web input” record & playback utility with a few commands added to make it a rudimentary testing system. I now use it for testing the WordPress plugin base functionality with limited effort.   Spending an extra 10 minutes writing a test case pays off in numerous “one-click-and-done” script runs in the future when I want to do something like “make sure the Pro Pack name search is not broken” after a new release.
The premise is simple, when you add Selenium IDE to your browser as a plugin you get a menu option in the browser “Selenium IDE”.   You can record a script by clicking a record button, “do you web thing”, then stop recording.  You now have a script outline.   Click the “run this button” on the interface and the script runs again.
One caveat.   The recorded scripts are not very good.  They get the job done for a quick start, but you are much better off spending and extra 5 minutes and writing the test commands by hand. They are far more efficient and accurate.

Getting Started

When you select it a new popup window opens with a simple test case table on the left and commands table on the right.   The Test Case table is mostly for Test Suites (groups of test cases you run in sequence) so we’ll ignore it for now.    On the right side is the commands and it start out with a “blank slate” of commands.   I have another blog post about the commands I use that handle 90% of my test scripts that you can use as a quick cheat-sheet.
To start a new script you use the right-side command window.  The general command sequence is to  click on a new blank line, start typing a command in the bottom-of-screen command box and press enter to auto-complete, enter a target which identifies an on-screen element in jQuery-like fashion, and a value for certain commands.  Repeat.

An Example Session

Here is how I create a simple test to make sure SLP Pro Pack is installed and allowing lat/long editing to occur:
  • Click the first blank line.
  • Select command on the bottom entry form.
  • Start typing “open”.  This is the “open  a web page in same window” command.
  • Select target.  type the relative path (you can use a full http address, but I want my scripts to run on any server)
  • Click on the next blank line & continue building out my script.

I won’t bore you with each command, here is a screen shot of the Pro Pack Edit Location lat/long script that is also on GitHub.

selenium script example
selenium script example


The commands are detailed in my other post, but the quick summary:

  • open = open a web page
  • waitForElementPresent = pause execution until something that needs to be on the page is present
  • clickAndWait = click an element and wait for the page to reload before continuing
  • type = type text into an HTML element, like an input box
  • assertValue = flag an error and STOP SCRIPT EXECUTION if the value does not match


The “target” element of the script commands can be tricky for people that do not know XHTML or JavaScript/jQuery style targets.   I find the easiest way to manage this is to make sure my web apps have discrete input names or IDs on most elements or useful and distinct class names for IDs that may be dynamic like “location-id-33”.   With a unique name or ID you can get to your target element easily, just type name=foo or id=bar and you are there if it is the only element with that ID or name.

For items without a discrete name or with multiple instances you can combine XHTML-like references with other elements.   Two key things to remember about this, using a single-slash means “exactly at this point in the document hierarchy and double-slashes means “first found”.     For example /table/thead/tbody/tr[1] is THE first row after the table, thead, tbody elements.  If any are missing it will fail.    In contrast /table//tr[1] will meant the first table row that can be located after the first table in the document.    I often mix-and-match “select by name” and the double-slash “first found” options so that something like this shows up:


This is useful in WordPress where I can never be certain that a theme will not change the page structure.  In this case it says “find the first table element with an id set to foo, within that find the second tr element (since a theme/plugin may throw in some thead or other element I continue the // format), find the second th element in that row, and select the first hyperlink with a class set to ‘bar’.

Targets take some getting used to, but luckily you can test your “guess” at the right path after it is entered with the “find” button that will go show you which element it thinks you mean on the page that is currently rendered in the browser window.

What I’ve Learned

A couple of important things I’ve learned along the way.   First, use waitForElementPresent judiciously.   I usually put this in place before I interact with the first item on the screen.  The “…AndWait” commands wait for the page to load but with so much jQuery page loaders out there it is common for the element you need to not be ready when the page first comes online.   The “waitFor…” commands can wait a long time and will not always flag an error if they time out.    Use “assert…” whenever something critical must be on the page or to flag a script as failing.   “assert…” is NOT the only way a script will fail, which is a feature I like about Selenium IDE.  If you try to click an element and it is not there it fails the script but tries to continue running.  This makes it very easy to write light-weight test scripts.

No Excuses

Overall it is not as robust as many testing platforms, but that is a good thing IMO.   Because it is light & easy you can get Selenium IDE in place and get your first test scripts online in well under an hour.    That means you really have no excuse not to be doing at least RUDIMENTARY repetitive task testing on your web apps.

I’ve started using this to test my WordPress plugins and try to add at least one new short test case in each plugin release.  It adds about 10-15 minutes on average to the test cycle but it means one more feature is tested before each release.  Even now with just a dozen test suites I’ve prevented at least two significant functional bugs from getting out to the public.

Use Selenium IDE and do some web tests.   The user community will thank you for it.

### Technorati Claim Code CGBQWRFD3GA5 ###