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.

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.

Selenium IDE icons

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.

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:

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.

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.

To add comments to your tests, use the following steps:

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.

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.

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:

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.

To see how this works, let's work through the following example:

These two steps are quite useful when your tests are not running and you want to execute a specific command.

If you have the Selenium IDE open from the previous steps, click on the File menu.

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.

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.

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:

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.