Test automation has grown in popularity over the years because teams do not have the time or money to invest in large test teams to make sure that applications work as they are expected to. Developers also want to make sure that the code they have created works as they expect it to.
Developers use a multitude of different testing frameworks to test different aspects of the system. Selenium is one of the most well-known testing frameworks in the world that is in use. It is an open source project that allows testers and developers alike to develop functional tests to drive the browser. It can be used to record workflows so that developers can prevent future regressions of code. Selenium can work on any browser that supports JavaScript since Selenium has been built using JavaScript.
In this chapter, we will cover the following topics:
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
So let's get on with it...
Before we start working through this chapter you need to make sure that Mozilla Firefox is installed on your machine. If you do not have Mozilla Firefox installed, you will need to download it from http://www.getfirefox.com/.
Selenium IDE is a Firefox add-on developed originally by Shinya Kasatani as a way to use the original Selenium Core without having to copy Selenium Core onto the server. It has been developed using JavaScript so that it can interact with DOM (Document Object Model) using native JavaScript calls.
Selenium IDE was developed to allow testers and developers to record their actions as they follow the workflow that they need to test.
Now that we understand what Selenium IDE is, it is a good time to install the Selenium IDE. By the end of these steps, you will have successfully installed the Selenium IDE on your computer.
Click on the download link for Selenium IDE. You may get a message saying Firefox prevented this site (seleniumhq.org) from asking you to install software on your computer. If you do, click on the Allow button.
A pop up will appear, as seen in the next screenshot:
Once the countdown has finished, the Install button will become active and you can click on it. This will now install the Selenium IDE as a Firefox add-on.
Once the installation process is complete, it will ask you to restart Firefox. Click on the Restart button. Firefox will close and then reopen. If you have anything open in another browser, it might be worth saving your work as Firefox will try to go back to its original state, but this cannot be guaranteed.
Once the installation is complete, the Add-ons window will show the Selenium IDE and its current version.
Selenium IDE has been installed, so let's take some time to familiarize ourselves with it. This will give us the foundation that we can use in later chapters.
Open up Selenium IDE by going through the Tools menu in Mozilla Firefox. The steps are Tools | Selenium IDE. The window that will appear should be similar to the next screenshot.

Starting from the top, I will explain what each of the items is:
Base URLâThis is the URL that the test will start. All open commands will be relative to the Base URL unless a full path is inserted in the open command.
Speed SliderâThis is the slider under the Fast Slow labels on the screen.
âRun all the tests in the IDE.
âRun a single test in the IDE.
âPause a test that is currently running.
âStep through the test once it has paused.
âThis is the record button. It will be engaged when the test is recording.
âThis allows you to run your tests using the Selenium Core TestRunner and not Selenium IDE. When pressed, it will open up Firefox to the
TestRunner
and it looks similar to the next screenshot:The Selenese Command select box has a list of all the commands that are needed to create a test. You can type into it to use the auto complete functionality or use it as a dropdown.
Target textbox allows you to input the location of the element that you want to work against.
The Find button, once the target box is populated, can be clicked on to highlight the element on the page.
Value textbox is where you place the value that needs to change. For example, if you want your test to type in an input box on the web page, you would put what you want it to type in the value box.
The Test table will keep track of all of your commands, targets, and values. It has been structured this way because the original version of Selenium was styled on FIT tests. The tests were originally designed to be run from HTML files and the IDE keeps this idea for its tests. If you click on the Source tab, you will be able to see the HTML that will store the test. Each of the rows will look like:
<tr> <td>open</td> <td>/chapter1</td> <td></td> </tr>
The area below the Value textbox will show the Selenium log while the tests are running. If an item fails, then it will have an [error] entry. This area will also show help on Selenium commands when you are working in the Command select box. This can be extremely useful when typing commands into the Selenium IDE instead of using the record feature.
Now that we have installed Selenium IDE and understood what it is, we can think about working through our first tests. There are a few things that you need to consider when creating your first test. These rules apply to any form of test automation but need to be adhered to especially when creating tests against a User Interface.
Tests should always have a known starting point. In the context of Selenium, this could mean opening a certain page to start a workflow.
Tests should not have to rely on any other tests to run. If a test is going to add something, do not have a separate test to delete it. This is to ensure that if something goes wrong in one test, it will not mean you have a lot of unnecessary failures to check.
Tests should only test one thing at a time.
Tests should clean up after themselves.
These rules, like most rules, can be broken. However, breaking them can mean that you may run into issues later on, and when you have hundreds or even thousands of tests, these small issues can mean that large parts of a test suite are red.
With these rules in mind, let us create our first Selenium IDE test.
We are going to record our first test using Selenium IDE. To start recording the tests, we will need to start Mozilla Firefox. Once it has been loaded, you will need to start the Selenium IDE. You will find it under the Tools menu in Mozilla Firefox. Note that the record button is engaged when you first load the IDE.
To start recording your tests:
Change the Base URL to the Base URL of the application under test. In this exercise, we will do it against http://book.theautomatedtester.co.uk/.
Click on the radio button.
Change the value of the Select.
Click on the link.
-
Your test has now been recorded and should look the like the previous screenshot. Click on the play button that looks like this:
.
Once your test has completed, it will look similar to the next screenshot:
We have successfully been able to record our first test and played it back. As we can see, the Selenium IDE has tried to apply the first rule of test automation by specifying the
open command. It has set the starting point of the test, in this case /chapter1
, and then it began stepping through the workflow that we want to record.
Once all the actions have been completed, you will see that all of the actions have a green background. This shows that they have completed successfully. On the left-hand side, you will see that it has completed 1 successful test, or run, that is, in Selenium IDE. If you were to write a test that failed, the Failures label would have a 1 next to it.
In the previous steps, we were able to record a workflow that we would expect the user to perform. It will test that the relevant bit of functionality is present, such as buttons and links to work against. Unfortunately, we are not checking that the other items on the page are there or if they are visible when they should be hidden. We are going to work against the same page as before, but we shall make sure that different items are on the page.
There are two mechanisms for validating elements that are available on the application under test. The first is assert: this allows the test to check if the element is on the page. If it is not available, then the test will stop on the step that failed. The second is verify: this also allows the test to check whether the element is on the page, but if it isn't, then the test will carry on executing.
To add the assert or verify to the tests, we need to use the context menu that Selenium IDE adds to Firefox. All that one needs to do is right-click on the element if on Windows or Linux. If you have a Mac, then you will need to do the two-finger click to display the Context menu.
When the Context menu appears, it will look like the next screenshot with the normal Firefox functions above it.

Open the IDE so that we can start recording.
Set the Base URL to http://book.theautomatedtester.co.uk/.
Click on
Chapter1
.Click on the radio button.
Change the select to Selenium Grid.
Verify that the text on the right-hand side of the page has Assert that this text is on the page. You can see the command in the previous screenshot.
Verify that the button is on the page. You will need to use the context menu for this.
Now that you have completed the previous steps, your Selenium IDE should look similar to the next screenshot:
If you now run the test, you will see it has verified that what you are expecting to see on the page has appeared. Notice that the verify commands have a darker green. This is to show that they are more important to the test than moving through the steps. The test has now checked that the text we required is on the page and that the button was there too.
What would happen if the verify command did not find what it was expecting? The IDE would have thrown an error stating what was expected was not there, but it carried on with the rest of the test. We can see an example of this in the next screenshot:

The test would not have carried on if it was using assert as the mechanism for validating that the elements and text were loaded with the page.
We have just seen that we can add asserts or verification to the page. Selenium IDE does not do this when recording, so it will always be a manual step. We saw that if we use the assert command and it fails, it will cause the test to stop, whereas the verify command allows the test to carry on after a failure. Each of these has their merits.
Recreate the test that you have just done but using the assert methods available from the context menu in Firefox.
Some of the verify and assert methods are:
Selenium verifies items on the page when it is recording steps.
True
False
What is the difference between verify and assert?
If you wanted to validate that a button, which has appeared, is on a page, what two commands would be the best to use?
verifyTextPresent
/assertTextPresent
verifyElementPresent
/assertElementPresent
verifyAlertPresent
/assertAlertPresent
verifyAlert
/assertAlert
Before we carry on further with Selenium, it would be a good time to mention how to create comments in your tests. As all good software developers know, having readable code with descriptive comments can make maintenance in the future much easier. Unlike in software development, it is extremely hard, almost impossible, to write self-documenting code. To combat this, it is good practice to make sure that your tests have comments that future software testers can use.
To add comments to your tests, use the following steps:
In a test that was created earlier, right-click on a step, for example, the verify step.
The Selenium IDE context menu will be visible, as seen in the next screenshot:
Click on the Insert New Comment. A space will appear between the Selenium commands.
Click on the Command textbox and enter in a comment so that you can use it for future maintenance. It will look similar to the next screenshot:
We have just had a look at how to create comments. Comments will always appear as purple text in the IDE. This, like in most IDEs, is to help you spot comments quicker when looking through your test cases. Now that we know how to keep our tests maintainable with comments, let's carry on working with Selenium IDE to record, tweak, or replay our scripts.
Web applications unfortunately do not live in a single window of your browser. An example of this could be a site that shows reports. Most reports would have their own window so that people can easily move between them.
Unfortunately, in testing terms, this can be quite difficult to do, but in this section we will have a look at creating a test that can move between windows.
Working with multiple browser windows can be one of the most difficult things to do within a Selenium test. This is down to the fact that the browser needs to allow Selenium to programmatically know how many child browser processes have been spawned.
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.
Open up the Selenium IDE and go to the
Chapter1
page on the site.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.
Once the window has loaded, click on the Close the window text inside it.
Add a verify command for an element on the page. Your test should now look similar to the next screenshot.
Click on the Close the window link.
Verify the element on the original window.
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.
In the next example, we are going to open up two pop-up windows and move between them and the parent window as it completes its steps.
Start the Selenium IDE and go to
Chapter1
on the website.Click on the first link that will launch a pop-up window.
Assert the text on the page.
Go back to the parent window and click on the link to launch the second pop-up window.
Verify the text on the page.
Move to the first pop-up window and close it using the close link.
Move to the second pop-up window and close it using the close link.
Move back to the parent window and verify an element on that page.
Run your test and watch how it moves between the windows. When complete, it should look similar to the next screenshot:
Web applications today are being designed in such a way that they appear the same as desktop applications. Web developers are accomplishing this by using AJAX within their web applications. AJAX stands for Asynchronous JavaScript and XML due to the fact that it relies on JavaScript for creating asynchronous calls and then returning XML with the data that the user or application requires in order to carry on. AJAX does not rely on XML anymore, as more and more people move over to JavaScript Object Notation (JSON), which is more lightweight in the way that it transfers the data. It does not rely on the extra overhead of opening and closing tags that is needed to create valid XML.
In our first example given next, we are going to click on a link and then assert that some text is visible on the screen:
Start up the Selenium IDE and make sure that the Record button is pressed.
Click on the text that says Click this link to load a page with AJAX.
Assert the text that appears on your screen. Your test should appear similar to the next screenshot. Selenium IDE will generate all the locators that are needed in this test:
Run the test that you have created. When it has finished running, it should look similar to the next screenshot:
Have a look at the page that you are working against. Can you see the text that the test is expecting? You should see it, then why has this test failed? The test has failed because when the test reached that point, 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 to our test so that our tests pass in the future.
Right-click on the step that failed so that the Selenium IDE context menu appears.
Click on Insert New Command.
In the Command select box, type
waitForElementPresent
or select it from the drop-down list.In the Target box, add the target that is used in the verifyText command.
Run the test again, and it should pass this time.
Selenium does not implicitly wait for the item that it needs to interact with, so it is seen as good practice to wait for the item that you need to work with and then interact with it. The waitFor
commands will timeout after 30 seconds by default, but if you need them to wait longer, you can specify the tests by using the setTimeout command. This will set the timeout value that the tests will use in future commands.
In the previous examples, we waited for an element to appear on the page. There are a number of different commands that we can use to wait. The following commands make up the waitFor
set of commands, but this is not an exhaustive list:
A number of these commands are run implicitly when other commands are being run. An example of this is the clickAndWait
command. This will fire off a click
command and then fire off a waitForPageToLoad
. Another example is the open
command, which only completes when the page has fully loaded.
If you are feeling confident, then it would be a good time to try different waitFor
techniques.
If an element got added after the page has loaded, what command would you use to make sure the test passed in the future?
waitForElementPresent
pause
assertElementPresent
Sometimes there is a need to store elements that are on the page to be used later in a test. This could be that your test needs to pick a date that is on the page and use it later so that you do not need to hardcode values into your test.
Once the element has been stored, you will be able to use it again by requesting it from a JavaScript dictionary that Selenium keeps track of. To use the variable, it will take one of the following two formats: it can look like ${variableName}
or storedVars['variableName']
. I prefer the storedVars
format, as it follows the same format because it is within Selenium internals.
To see how this works, let's work through the following example:
Open the Selenium IDE and switch off the Record button.
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.
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.Click on the row below the storeText command in Selenium IDE.
Type the command
type
into the Command textbox.Type
storeinput
into the target box.Type
javascript{storedVars['textOnThePage'];}
into the value box.Run the test. It should look similar to the next screenshot:
Once your test has completed running, you will see that it has placed Assert that this text is on the page into the textbox.
We have successfully created a number of tests and have seen how we can work against AJAX applications, but unfortunately creating tests that run perfectly first time can be difficult. Sometimes, as a test automater, you will need to debug your tests to see what is wrong.
To work through this part of the chapter, you will need to have a test open in the Selenium IDE.
These two steps are quite useful when your tests are not running and you want to execute a specific command.
Highlight a command.
Press the X key: This will make the command execute in the Selenium IDE.
When a test is running, you can click on the Pause button to pause the test after the step that is currently being run. Once the test has been paused, the Step button is no longer disabled and you can click on it to step through the test as if you were stepping through an application.
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.
The echo
command is also a good way to write something from your test to the log. This is equivalent to Console.log
in JavaScript.
If you have the Selenium IDE open from the previous steps, click on the File menu.
Click on New Test Case.
You will see that Selenium IDE has opened a new area on the left-hand side of the IDE, as seen in the next screenshot:
You can do this as many times as you want, and when the Run Entire Test Suite button is clicked, it will run all the tests in the test suite. It will log all the passes and failures at the bottom of the Test Case box.
To save this, click on the File menu and then click on Save Test Suite and save the Test Suite file to somewhere convenient.
Changing the name of the test case to something a lot more meaningful, this can be done by right-clicking on the test and clicking on the Properties item in the context menu.

You can now add meaningful names to your tests and they will appear in the Selenium IDE instead of falling back to their filenames.
We have managed to create our first test suite. This can be used to group tests together to be used later. If your tests have been saved, you can update the test suite properties to give the tests a name that is easier to read.
Saving tests is done in the same manner as saving a test suite. Click on the File menu and then click on Save Test Case. This will give you a save dialog, save this somewhere that you can access later. When you save your tests and your test suite, Selenium IDE will try to keep the relationships between the folders in step when saving the tests and the test suites.
We have seen our tests work really well by recording them and then playing them back. Unfortunately, there are a number of things that Selenium cannot do. Since Selenium was developed in JavaScript, it tries to synthesize what the user does with JavaScript events. However, this does mean that it is bound by the same rules that JavaScript has in any browsers by operating within the sandbox.
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 thehtml5div
element. The test will tell you that it has completed the command but the UI will not have changed, as shown in the next screenshot: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.
By now you should be feeling rather confident about using Selenium IDE. Try creating a test against your favorite web application. Try to record a test again making sure to add verifications along the way so that your test does what you expect. Run the test and have it pass.
Now try creating the same test by typing in the commands needed to create the test. Have you created a better test by hand or by using the record/tweak and playback?
We learned a lot in this chapter about Selenium IDE, learning how to create your first test using the record and replay button, and understanding some of the basic concepts such as moving between multiple windows that can appear in a test, and to save our tests for future use.
Specifically, we covered the following topics:
How to install Selenium IDE: We started by downloading Selenium IDE from http://seleniumhq.org.
What the Selenium IDE is made up of: The breakup of Selenium IDE allowed us to see what makes up the Selenium IDE. It allowed us to understand the different parts that make up a command that will be executed in a test as well as its basic format.
Recording and replaying tests: Using the Selenium IDE to record a workflow that a user will do through their tests. We also had a look at verifying and asserting that elements are on the page and that the text we are expecting is also on the page.
How to add comments to tests: In this section of the chapter, we saw how to add comments to the tests so that they are more maintainable.
Working with multiple windows: Applications today can have pop-up windows that tests need to be able to move between.
Working with AJAX applications: AJAX applications do not have the items needed for the tests when the tests get to commands. To get around this, we had a look at adding
waitFor
commands to the tests. This is due to the fact that Selenium does not implicitly wait for elements to appear in the page.Storing information in variables: There is always something that is on the page that needs to be used later, but unfortunately you will not know what the value is before the test runs. This section showed us how we can record items into a variable and use it later in a test.
Debugging tests: Creating tests does not always go according to plan, so in this section we saw some of the different ways to debug your tests.
Saving test suites: Finally we saw how we can save tests for future use, and how we can save them into different groups by saving them into test suites.
We also discussed what cannot be tested using Selenium IDE. We saw that Silverlight and Flex/Flash applications could not be tested and that when working with a number of HTML5 elements, the tests say that they have completed the tasks even though the UI has not changed. In later chapters, we will discuss different mechanisms that we can use within our tests that might be useful against HTML5 elements on the page. Remember that if you do get stuck, you can always have a look at http://seleniumhq.org/docs/
, which holds the official documentation.
Now that we've learned about Selenium IDE, we're ready to look at all the different techniques to find elements on the pageâwhich is the topic of the next chapter.