Selenium scripting conventions

Conventions
These are suggested guidelines, or rules of thumb, for writing or editing Selenium scripts, based on real-world experience.

Base URL
Set a standard Base URL for your scripts. Assuming you have multiple environments, such as development, test, staging, and production, you may wish to configure your Base URL with an environment-specific variable.

Record but Edit
Selenium recording is great but does not do everything we need to do. After you record your script, be prepared to edit it some by hand.

HTML Format
Maintain each test in HTML format. This should be the "gold" copy of the test. The idea here is that you can edit HTML tests in Selenium IDE. The other formats, such as Java, can be generated automatically from HTML, but there is no robust automated way to go the other direction, for example from Java to HTML. Therefore once you leave HTML, there is no easy way back. If you modify your tests after translating them to Java or another language, you may be able to automate that process in order to make the entire system work easier for you.

Create Examples or Templates
Create some initial example or template tests and have the entire automation team vet them. Once best practices are in place, it will be easier for all to maintain tests, regardless of the original author. Just as with general programming, communication is key. Even with templates, hold regular code reviews, especially at the beginning of your automation effort.

Feature IDs
At the top of each script, where applicable, enter a comment "FeatureID=Xxxxx" where Xxxxx is a unique identifier of the main feature covered. This sort of convention will make it easier for you to integrate with test coverage reporting tools in the future.

Author's Name
Also at the top of each script, enter a comment "Author=Name" where Name is your name or handle. This makes it easier to resolve questions about how the script works or what its purpose is.

Setup and Cleanup
Test independence helps ensure the robustness of the execution environment. Therefore it is a good idea to have each script attempt to setup any environment it needs and likewise clean up after itself when finished. One example of such behavior is to start with a logout and end with a logout. Likewise, the script should also undo any data changes it makes. However, this approach is still no substitute for "harder" data cleanup and preparation. Before any test suite executes, the entire test environment should always begin with a known configuration and data set. That is generally something you will have to do outside Selenium.

Minimize Assumptions
Even though scripts should clean up after themselves, it is also wise not to assume the system is in the exact state that it was last time you recorded the script. Try to minimize the assumptions the script makes. For example, only sign in as a user you know will be available at all times.

Use clickAndWait
Instead of the "click" command, use the "clickAndWait" command. This waits for the new page to load fully before continuing. Unfortunately when recording scripts, Selenium usually places the "click" command everywhere, so you have to change them by hand.

Use check and uncheck
Selenium, by default, also uses the "click" command for interacting with checkboxes. Unless you specifically want a test that toggles a checkbox and doesn't care what specific value it ends up with, use the "check" and "uncheck" commands instead of "click".

Test Something
It's important to include "assertXxxxXxxx" statements in your script. These are the actual meat of the test. "assertTextPresent", "assertTextNotPresent", and "assertElementPresent", are your friends.

Test the Test
Run your script a couple times after you record (and edit) it to make sure it runs repeatedly. If you have difficulty making your script repeatable, you may wish to raise the issue with your team to see if anyone else has discovered a solution.

If and when you convert your test from HTML to Java, especially if you run it remotely via Selenium RC on a different browser, test again. Browser differences can easily break tests if you are not careful.