Getting Started with Selenium – Chapter 2: How To Write a Good Acceptance Test

This post is the second in a series of “Getting Started with Selenium Testing” posts from Dave Haeffner, a noted expert on Selenium and automated testing, and a frequent contributor to the Sauce blog and Selenium community. This series is for those who are brand new to test automation with Selenium and a new chapter will be posted every Tuesday for the next two months.

In order to write Selenium tests that are maintainable, resilient, and performant, there are some simple guidelines to follow:

Each test needs to be concise (e.g., testing a single feature rather than multiple features) and independent (e.g., sets up its own data rather than relying on a previous test to do it). Doing this may require a mental shift, discipline, and more up front effort. But it will make a dramatic impact on the quality, effectiveness, and maintainability of your tests.

As your test suite grows, you should have multiple test files, each containing a small grouping of tests broken out by functionality that they're exercising. This will go a long way towards organization and maintenance as your test suite grows -- as well as faster execution times (depending on your approach to parallelization).

Each test file should be named appropriately, and each test within that file should have an informative name (even if it may be a bit verbose). Also, each test (or grouping of tests across test files) should be tagged with some helpful information to provide context and enable more flexible test execution (more on this approach in a future post). This way all or parts of your test suite can be run, and the results will be informative thanks to helpful naming.

At the heart of every test suite is some kind of a test runner that does a lot of the heavy lifting (e.g., test group execution, easy global configuration for setup and teardown, reporting, etc.). Rather than reinvent the wheel, you can use one of the many that already exists (there's more than one for every language). And with it you can bolt on third party libraries to extend its functionality if there's something missing -- like parallelization.

In order to effectively collaborate with other testers and developers, your test code must live in a version control system of some sort. Look to see what your development team uses and add your code to it. Otherwise, set up one of the following:

Keep in mind that your test code can live in a separate repository from the code of the application you're testing. Combining them may be advantageous, but if all you're doing is writing and running tests against web endpoints (which is a majority of what your testing will be with Selenium) then leaving your test code in a separate repository is a fine way to go. 

Dave is the author of Elemental Selenium (a free, once weekly Selenium tip newsletter that is read by hundreds of testing professionals) as well as a new book, The Selenium Guidebook. He is also the creator and maintainer of ChemistryKit (an open-source Selenium framework). He has helped numerous companies successfully implement automated acceptance testing; including The Motley Fool, ManTech International, Sittercity, and Animoto. He is a founder and co-organizer of the Selenium Hangout and has spoken at numerous conferences and meetups about acceptance testing.