PRACTICUM: Selenium 1.0 Testing Tools: Chapter 1: Selenium IDE

This is the first entry for the TESTHEAD PRACTICUM review of PACKT Publishing's book Selenium 1.0 Testing Tools Beginners Guide by David Burns. As such, the emphasis on this type of review is the actual exercises and the practical applications of what we learn. Rather than reprint out the full listing of the exercises in the book (and there are a bunch of them, as that is the format of this particular title), much of these chapters are going to be a summary of the content, some walk-through of application, and my take on what I see and do.

Some notes on this first foray into this type of review. Selenium 1.0 Testing Tools is full of examples, "try it yourself" instructions and explanations of what happened. The book’s cover states “Learn by doing: less theory, more results”. In short, this may well be the perfect book to experiment with this form of review, as the focus will be less on the concepts and more on the actual implementation and methods suggested.

Chapter 1, Getting started with Selenium IDE:

In this introductory chapter, the following topics and goals are introduced to the reader:

• What is Selenium IDE
• Recording our first test
• Updating tests to work with AJAX sites
• Using variables in our tests
• Debugging tests
• Saving tests to be used later
• Creating and saving test suites

The Selenium framework of tools covers a number of applications and technologies, but in most tutorials and examples on the web, Selenium for most users starts with Selenium IDE. The Selenium IDE is a Firefox plug-in that allows the user to record and sequence test steps, identify values, change and modify test criteria. This is a logical first place to start, since with the IDE, users can create tests quickly and get a feel for the inner workings of the application. Note: Firefox is a prerequisite, as Selenium IDE runs inside of it. Firefox as of the writing of this review is at version 3.6.13 (download from http://getfirefox.com/) and install it if you haven’t already.


Install Selenium IDE


To get the IDE, the first step is to go and download the latest version, which is found at http://seleniumhq.org/download/. Selenium IDE version with this review writing is at 1.0.10.


Selenium IDE comes as an xpi file, which Firefox handily installs directly into the browser.


Once it’s downloaded, the installation asks if it’s OK to install the IDE. Click install and away you go. Restart Firefox and the IDE is read to be used. Just click on the Tools Menu item, select Selenium IDE, and you’re ready to get your first tests started.


Touring Selenium IDE

Selenium IDE has some simple controls to be aware of. They are as follows:

• Base URL—This is the URL where the tests reference and start. All open commands will be relative to the Base URL unless a full path is inserted in the open command.
• Speed Slider—This allows the user to control the overall speed of test execution (fast/slow)
• The Play button /w three bars allows the user to run all of the tests in the IDE.
• The Play button /w a single lit-up bar will let the user run a single test in the IDE.
• The Pause button allows the user to pause a test that is currently running.
• The button with the blue downward pointing arrow is the Step Mode Playback option; it allows the user to step through the individual test steps one at a time when the test has been paused.
• The Red record button is, you guessed it, the Record button. This allows the user the ability to record a sequence of steps to make a test suite.
• The Playback button in the square is there to allow tests to be run in Selenium Core TestRunner.
• The Selenese Command select box lists all the commands needed to create a test (more on Selenese in a bit).
• The Target text box allows you to input the location of the element that you want to work against.
• The Find button, once the target box is populated, when clicked will highlight the element listed on the page.
• The Value textbox is where you place the value to change. You can use this option to enter text into a form’s text box, for example.
• In the middle of the IDE is a Test Table. This table lists all of the combinations of commands, targets, and values. Selenium owes much of its initial design to a tool called FIT. Tests were originally designed to run from HTML files (and thus have structured the test data into HTML tables). The IDE keeps this format. Clicking on the Source tab shows the HTML source code and the test structure.
• The bottom of the IDE shows a number of links. The first is the Log, which keeps track of times tests run and error messages. If a tests item fails an [error] entry is created. The others we will cover in a later chapter.

Creating the First Tests


Just like any tool, Selenium IDE tests will only be as good and as robust as the user makes them. In its simplest sense, the IDE will record and playback procedures and steps as they are entered. It shares this with many automation tools, and likewise, it also shares the brittleness of those tests. To make tests robust and less prone to errors, keep these thoughts in mind:

• Make sure tests start at a known state, such as from a particular page or base URL.
• Keep your tests compartmentalized. Have them do one thing or cover just one area.
• Make sure that any tests that have set-up have a corresponding break down (good tests clean up after themselves :) ).

The test example uses http://book.theautomatedtester.co.uk/ for its test URL. First and foremost, this URL actually takes the user to the Selenium Beginners Guide Page (I mention that because I have been infuriated many times when I get a book that is a couple of years old, go to their sample sites, and the sites are down or expired. Granted, not to be expected with a new book, but very nice to see off the bat that the practice examples won’t be for naught :) ).


The first example is a good and basic one, but it omits a step “0”, which is to open the browser to the base URL page mentioned in Firefox itself. Not a big deal, but I found myself wondering why my output didn’t look the same. I figured it out quickly enough, but to save a little time, open up Firefox, use the base URL, and navigate to that page. THEN open up Selenium IDE, which will start in record mode automatically.

1. Make the base URL entry for the test be the one from the book (http://book.theautomatedtester.co.uk/).
2. Click on Chapter1 link.
3. Click on the radio button.
4. Change the value of the Select (the drop down menu with various Selenium products).
5. Click on the link (which brings the user back to the home page).

Once the test is recorded, click on the Single test playback button. The IDE will then walk through each of the steps in sequence, and if all goes according to plan, the steps will be colored green, you will have a successful run, no failures and a log listing of all steps performed like this:

[info] Executing: |open | / | |

[info] Executing: |clickAndWait | link=Chapter1 | |

[info] Executing: |click | radiobutton | |

[info] Executing: |select | selecttype | label=Selenium RC |

[info] Executing: |clickAndWait | link=Home Page | |

The book then has the users take a look and see if they can pass a Pop Quiz asking what language drives the IDE and if Selenium IDE runs on Windows Explorer (I’ll let the readers determine the answers to those questions on their own ;) ).


Updating Tests / Using Asserts


Our first test does perform some rudimentary steps, but what else can we do? We can add “asserts” to check if particular elements are on the page. An assert statement if it proves false will stop the test. By contrast a “verify” statement will aos check to see if an item is on the bage. If it fails, though, the test will continue.


To add the assert or verify to the tests, use the context menu that Selenium IDE adds to Firefox. This means to go to the actual page, click the mouse into a place on the screen or highlight a spot on the screen. Right-click to see the element (this method works for Windows & Linux. Mac users use the two-finger click method and display the Context menu).


The context menu will show what values can be selected based on where the mouse pointer is located. Each element will show different options, but they will generally be in the following format:

• open
• assertTextPresent
• verifyTextPresent
• verifyValue
• storeElementPresent

There are other options beyond these, but this is a good starting point.


With this let’s modify the test to verify that there are specific items on the page. Record another example test .

1. Open the IDE so that we can start recording.
2. Set the Base URL to http://book.theautomatedtester.co.uk/.
3. Click on Chapter1.
4. Click on the radio button.
5. Change the select to Selenium Grid.
6. Verify that the text on the right-hand side of the page has Assert that this text is on the page.
7. Verify that the button is on the page. You will need to use the context menu for this.

When you run this test this time, sections that pass show a green background and assert statements that pass show a background that is darker green to differentiate the assert statements. The Log below gives an example output (I added some additional assert statements for variety)

[info] Executing: |storeElementPresent | radiobutton | |

[info] Executing: |verifyValue | radiobutton | on |

[info] Executing: |click | selected(1234) | |

[info] Executing: |verifyValue | selected(1234) | on |

[info] Executing: |assertElementPresent | selected(1234) | |

[info] Executing: |assertTitle | exact:Selenium: Beginners Guide | |

Tests that go beyond the very simple will need to be maintained at some point, possibly by you, possibly someone else. To make life a little more pleasant, it’s helpful to use comments in your tests, like this:

• go to a selenium test and select a step.
• Right-click on the selected item.
• Click on Insert New Comment
• Click on the Command Text box and type your comment (“This checks to make sure the radio button is present”). 

Comment text appears as purple in the table section to differentiate it from commands.


So this is all good and straightforward when dealing with a single window and the items on the screen. How about dialog windows, or other pop-ups? Can we work with those in the same way? Yep, but it has some challenges. The browser needs to let Selenium know how many “child browser processes” have been spawned and keep track of them when they are open and when they are closed and in which order.


In the examples given next, we will click on an element on the page, which will cause a new window to appear. If you have a pop-up blocker running, it may be a good idea to disable it for this site while you work through these examples.

1. Open up the Selenium IDE and go to the Chapter1 page on the site.
2. Click on one of the elements on the page that has the text Click this link to launch another window. This will cause a small window to appear.
3. Once the window has loaded, click on the Close the window text inside it.
4. Add a verify command for an element on the page. Your test should now look similar to the next screen-shot.
5. Click on the Close the window link.
6. Verify the element on the original window.

The text below is verbatim from the book, hence the Red Text:

In the test script, we can see that it has clicked on the item to load the new window and then has inserted a waitForPopUp. This is so that your test knows that it has to wait for a web server to handle the request and the browser to render the page. Any commands that require a page to load from a web server will have a waitFor command. 

The next command is the selectWindow command. This command tells Selenium IDE that it will need to switch context to the window called popupwindow and will execute all the commands that follow in that window unless told otherwise by a later command. 

Once the test has finished with the pop-up window, it will need to return to the parent window from where it started. To do this we need to specify null as the window. This will force the selectWindow to move the context of the test back to its parent window.

The next example in the text shows two windows being spawned and closed and how the IDE keeps everything straight using unique IDs for each window.


Selenium w/ AJAX


AJAX applications use JavaScript to creating asynchronous calls to a server and then return XML with the data that the user or application requested. AJAX also uses JavaScript Object Notation (JSON) since it is more lightweight in the way that it transfers the data.


The text walks the user through a number of examples that build and show how the test fails because it cannot access the element containing the text was not loaded into the DOM. This is because it was being requested and rendered from the web server into the browser. To remedy this issue, we will need to add a new command (waitForElementPresent) to our test so that our tests pass in the future. There are a variety of waitFor techniques to use. Explore at your leisure :).


Storing Variables


You can store elements that will be needed to enter in on the page later on for a test. You can call these values by requesting them from a JavaScript dictionary that Selenium tracks. The author suggests using storedVars['variableName'] format, since this format is similar to how Selenium is coded internally. The following example shows how to create a variable to call for a later run.

1. Open the Selenium IDE and switch off the Record button.
2. Right-click on the text Assert that this text is on the page, go to the storeText command in the context menu, and click on it. If it does not display there, go to Show all Available Commands and click on it there.
3. A dialog will appear similar to the next screenshot. Enter the name of a variable that you want to use. I have used textOnThePage as the name of my variable.
4. Click on the row below the storeText command in Selenium IDE.
5. Type the command type into the Command textbox.
6. Type storeinput into the target box.
7. Type javascript{storedVars['textOnThePage'];} into the value box.

Once your test has completed running, you will see that it has placed Assert that this text is on the page into the text-box.


Debugging


It’s possible to walk through individual tests by highlighting a specific command and then pressing the ‘x’ key. To create messages in the log for debug purposes, you can also create an ‘echo’ command, so that the words following get printed to the test log. If you are having issues with elements on the page, you can type in their location and then click on the Find button. This will surround the element that you are looking for with a green border that flashes for a few seconds.


Test Suites


In addition to running individual tests, we can also run multiple tests in order. This is called a test suite, and the playback button with multiple stacked bars allows us the option to do exactly that. Saving multiple tests with unique names differentiates the individual tests. Saving the suite groups all the tests under a unique suite name. Running the suite runs all of the tests in the suite.


So what can Selenium IDE not record?


As of the books writing, this is the list of items:

Silverlight and Flex/Flash applications, at the time of writing this, cannot be recorded with Selenium IDE. Both these technologies operate in their own sandbox and do not operate with the DOM to do their work.

HTML5, at the time of writing this, is not fully supported with Selenium IDE. A good example of this is elements that have the contentEditable=true attribute. If you want to see this, you can use the type command to type something into the html5div element. The test will tell you that it has completed the command but the UI will not have changed, as shown in the next screen-shot:

Selenium IDE does not work with Canvas elements on the page either, so you will not be able to make your tests move items around on a page.


Selenium cannot do file uploads. This is due to the JavaScript sandbox not allowing JavaScript to interact with \<\ input type=file \>\   elements on a page. The tests will be able to insert text, but will not be able to click on the buttons.


Bottom Line


That’s a pretty good run through for a Chapter 1. The examples presented are fairly straightforward and do not require much in the way of second guessing, though a few times I did have to go to the all commands listing to find the command value I was looking for. Also, there are steps where the user is clearly expecting to do something (interact with the browser, for example) and that step isn’t listed. This seems to me to not be an omission in the directions, but rather an expectation on the part of the author that the step in question is obvious. To be fair, after a couple of tries, I was able to read between the lines and realize a couple of times what was necessary, and from there, the steps flowed and the examples were easy to duplicate.