Selenium IDE is an indispensable tool for automated testing. If you’re a web developer or QA, you need to have Selenium tests to cover the basic functionality of your web site, and anything that you have to retest repeatedly.
One of the nice things about Selenium is that it allows you to record your actions in a browser, so you don’t have to type in the test script by hand. Still, though, there is almost always tweaking you need to do to get reliable tests. Here are my top tips:
- deleteAllVisibleCookies. Your tests will fail if they expect the user to be logged out, but they’re really logged in. To make sure they’re logged out, use the deleteAllVisibleCookies command to do exactly that.
- Watch out for click and clickAndWait. The clickAndWait command will click a link or button, then wait for the page to finish loading before executing the next step. The click command will click and then immediately execute the next step. So you always want to use clickAndWait when clicking a link that goes to a new page, or submitting a form. Usually Selenium IDE records these clicks as clickAndWait – but sometimes, for no particular reason I can discern, it records them as a click. You will probably need to change those to clickAndWait.
- waitForText for Ajax. If you’re using Ajax, you can’t clickAndWait, because the page doesn’t load. And you can’t just keep executing immediately, because the next step in the test case will usually run before your Ajax request completes. Running your tests at less than maximum speed can help, but that’s not very efficient. It’s better to add a waitForText command (or another waitFor… command) after everything you do that generates an Ajax request. Test for something that will show you the Ajax request finishes, before continuing. In my application, for example, sometimes I test that values are populated in a select dropdown, and sometimes I test that an “OK” icon has appeared on the screen.
- Test all the cases. Sometimes, Selenium is most useful when you have a lot of different combinations of behaviors. For example, my application interfaces via SSO (single sign-on) to another application. There are multiple places in the application that it interfaces, and there are three kinds of user that have different SSO abilities, leading to 22 different cases. As you can imagine, it’s easy for a fix for one feature to break another feature. So I wrote up the test cases in an Excel spreadsheet, then created a Selenium test for each of the 22 cases. Now I can rerun the test suite at any time to make sure all of the cases still work.
- Test what you can automate, not what you can’t. Not everything is easy to automate in Selenium. Don’t expect it to take the place of all your QA testing. And don’t give up on Selenium just because it can’t take the place of all your QA testing. Use it to cover as many cases as you reasonably can, and run it regularly to certify code updates, merges, and environments. Then continue to do manual QA as well.