We have been using Selenium successfully as an automated tool for Acceptance Testing all releases from our outsourcing provider. Even though we have written many of the testcases in ruby, using the IDE to create testcases in Selenese has been enough in many cases. Every release we receive is tested using the old test suites to make sure the new functionality does not break existing one, this step is also called regression testing. Selenium works great for applications with an already advanced user interface that will not change significantly over time any more. Otherwise a lot of time will be spent debugging the testcases themselves. One way around this is to use a fixed id for the elements used in testing, but that might not always be possible.
Tip:If you have access to the database, create a database dump after running a test suite. If you have to do manual tests in between test suites then create a db dump before AND after. This will make your life a lot easier if your tests are dependent on previous tests which they probably will be. Now if one of the tests in a test suite fails, you just reload the database and start the test suite again.
We used Selenium and found it to work very well with our AJAX enabled website, but it took some time to get the head around the topics described below. The following examples worked in Firefox 3.6.10 and Selenium IDE 1.0.7.
The documentation was pretty useful and the API covered most other topics not found in the documentation.
Selenium IDE documentation
Selenium Selenese Commands
Selenium 1.0 API
setTimout( timeout in milliseconds) –> setTimeout(5000) –> sets timeout to 5s
Once set, the timeout will stay at 5s.
AJAX or “in browser” popup
- Use waitForVisible if the element’s CSS attributes include “visibility:hidden” or “display:none”.
- Use waitforElementPresent if the element did not exist before. This will not work for the above situation because the element itself is present, even though it is not visible.
Tip:use waitFor commands in sequence if you are waiting for an element in a container. For example you have to test an AJAX action that populates a hidden DIV with a page from the server that contains input fields and then makes the DIV visible. As part of the test you most likely will have to populate these inputs fields. In that case use waitForVisible for the DIV container first and then use the waitForElementPresent for the first input field. Even though Selenium verified that the DIV is now visible, it still is not a guarantee that the browser already loaded the form with the inputs fields from the server. So the test will most likely behave slightly erratic, sometimes it passes and sometimes it will fail. Using a sequence of waitFor commands will make sure that the elements are available at the time of the test step.
But most of the time it is possible to deal with this pesky little alert boxes. When recoding the test using Selenium IDE the alert boxes appear as normal and the IDE will happily record a “assertConfirmation” command, but when running the test, no alert box shows up and the test often fails. It is important to know that alert boxes are NOT shown when running the test as noted in the Selenium documentation. And replacing assertConfirmation with waitForConfirmation most of the time allows the test to pass.
All commands use a positive confirm, so if you want to test the negative confirmation use chooseCancelOnNextConfirmation BEFORE the action that results in the alert box.
Drag & Drop
Even complicated actions like drag and drop can be implemented using the Selenium IDE only. In our case we had the following setup to test.
- Two DIVs side by side with ids “account” and “team”, the “account” DIV containing a table of account users not in a project team and the “team” DIV containing the table of the project team users.
- The users were distinguished using their unique email address and the table position for a specific user is dynamic in both DIVs.
- Dragging a user from the “account” into the “team” DIV also opened an “in browser” popup to choose the project roles for that user.
- Once the user was moved over in the “team” DIV, we needed to check that the email address was in the table of the “team” DIV.
||Click the left mouse button over the first user in the table (uses an Xpath locator)
||Store the email address of the user in the variable “email”
||Move the mouse over the the “team” DIV (using the id as locator)
||Now release the left mouse button over the “team” DIV
||Wait for the “in browser” popup “popup_div” to become visible
||//input[@id='roles_' and @name='roles‘ and @value=’4′]
||Tick a checkbox for the user to get that role in the team
||Press the submit button of the form for the roles. This also closes the “in-browser” popup
||Just for debugging, show the value for the variable “email”
||Now wait for the user with the unique text value “email” to appear in the “team” DIV
Tip:Don’t move the mouse when running a test that contains mouse movement commands, otherwise your mouse movements will interfere with Selenium and the test will very likely fail.
Tip:Use the echo command to check your variables in the log (works if set to info)