Selenium: What to do

In my last post, I went through some of the pros and cons of Selenium.

Now I'd like to go through some of the lessons I learned to keep Selenium tests maintainable and valuable for a team.

Run continuously. How often does a UX developer change the user experience? Isn't that their job? When things change in the UI, Selenium will break, that is the downside using the UI to drive our tests.  With CI servers becoming more and more popular, groups have gotten into the habit of running their tests after every commit, otherwise they rust. Why don't they do it with their Selenium tests? I have found after all of the other tests pass, kicking off your Selenium tests is the logical next step. We avoid test rust, a huge Herculean effort at the end of an iteration to make the tests all pass again when there is always so much time, and reduce the feedback cycle as much as possible.

Don't over reach. Do not make too many tests. These tests take a while to run. The more tests you create, the longer they take and the longer the feedback cycle. I've found that only testing your regression tests, or acceptance tests, is more than enough. By only testing the basics, you allow your QA members to do some exploratory testing to ensure that the application is working.

Practice the DRY principal religiously. Let me give you an example. You have an e-commerce site and the developers change something in step one of your checkout flow, but you have ten test which go through this flow. Do you want to find every place that you're calling the newly changed code? Trust me, hunting these references down becomes a wicked time sink. Instead, if you have a step which is repeated more than once, create a method for that step. You'll be happy that you do. which leads me to

Constantly refactor. These are not just some test scripts which people don't need to pay attention to. You will end up creating a DSL for your website with Selenium as the driver. If a method's name doesn't make sense, change it.. If there is code repetition, combine it. If there is any code which is not clear, refactor. You may not have your most senior people maintaining this code, but to reduce the costs, make sure they have opportunities to review this code.

Find ways to make the tests faster. Probably part of the last point, but it bears repeating. These tests are slow. If you can combine tests, do it. If you don't need to run ten times through a step, do it. If you can create data needed for the tests directly with a database connection, do it. Or if you can clan up after the tests without going through the UI, do it. The faster the tests, the shorter that feedback loop, and the smaller the costs are to your group to create, run and maintain these tests.

Use Web driver. With web driver, you don't need to start up an extra server in order to run your tests. Also, Selenium 2 uses web driver and it really is a big step forward.

If you have any question or comments, please don't hesitate to contact me.