What Are Test Automation Good Practices?

Image for post
Image for post
Photo by Nate Grant on Unsplash

A test automation project is a development project.

Test automation is achieved by writing code in a programming language, using an IDE and a unit testing framework that implements a test case.

Any good practices that apply to a development project apply then to a test automation project as well. To provide just a few examples:

  • YAGNI (you ain’t going to need it)
  • DRY (don’t repeat yourself)
  • fail fast
  • using a build process
  • unit testing
  • code reviews
  • no comments
  • write code defensively
  • use small classes, small methods, small packages
  • use 3rd party libraries
  • code refactoring
  • use continuous integration/deployment
  • use abstraction layers
  • use Design Patterns and Principles

Test automation projects follow also practices that are not found usually in application development projects.

  • Create structured, short, single purpose tests; each test should verify one thing only; if your test checks for example that a product can be added to a cart and then more products can be added, you should break the test in 2 smaller tests
  • Create independent tests that can be run in parallel; having dependent tests is a bad practice because if one of the tests fails, all subsequent tests that depend on it will fail as well; if all tests are independent, any failing test will have no impact on the remaining tests; also, dependent tests cannot be executed in parallel
  • Tests’ initial state should always be consistent; the initial state of a test should not depend on other tests; the test should always start from the same state
  • Compose complex tests from simple steps; tests should be based on an abstraction layer that implements the user interaction with the application; in Selenium projects, implementing the Page Object Model provides this abstraction layer by creating page classes for the user interaction with each page of the site; the objects of the page classes can then be used in the tests
  • Add validations in turn-over points; every time the application state changes, before interacting again with the application, the new state should be validated; for example, in a Selenium project, every time an action has as result a new page, before interacting with the new page, the code should verify that the new page is actually displayed in the browser
  • No sleep to improve stability; waiting for a number of seconds before executing an action is a bad practice because if the application is very slow, the waiting is insufficient; if the application is fast, then the waiting is useless; instead of waiting for a set time, the code should use synchronization mechanisms such as Waits; the Selenium WebDriver bindings for Java has for this purpose the WebDriverWait and ExpectedConditions classes
  • Reduce the occurrences of conditions; use assertions to validate the automated tests; the automation code should not use conditions for verifications but assertions from the unit testing framework
  • Use setup and teardown; the environment needs to be prepared before the automated tests execute and cleared after the automated tests are done
  • Use efficient locators; good test automation code relies on efficient locators, such as by id or name for Selenium projects
  • Test early and test often; the automated tests should be executed as often as possible in a CI/CD environment
  • Use data driven instead of repeated tests; let’s say that your UI test needs to be executed on a desktop browser, on a large tablet browser, on a smart phone browser; it is very inefficient to have a test for each platform; instead, a single test should be used that gets the platform info from a data provider
  • Use a stable test environment; automated tests should be executed on stable test environments that are not shared with the testing and development teams; it is very difficult to run automated tests on test environments that are updated all the time with new changes and that are shared by multiple teams and multiple projects
  • Name your tests wisely; tests should use clear names that explain the purpose of the test, for example, Product_is_added_to_cart()
  • Take screenshots for failure investigation; screenshots should be taken automatically every time a test fails because of a failed assertion or because of an exception; the screenshot will show the state of the application when the error/failure happened; the screenshot name should include the test name and the day and time of the error/failure;
  • Throw informative exceptions for runtime errors; the exception should include not only the exception type and message but any other information that can highlight fast what went wrong, why and where
  • Setup detailed automation test reporting; it is a good practice to have self-descriptive reports for each automated test that highlight all steps executed by the test; the reports can also include the screenshot of the application page/window before each step is executed
  • Do not rely only on UI test automation; API test automation should be considered as well
  • Do not automate tests that do not provide a lot of value; negative tests, boundary tests, look-and-feel tests are less important that functionality tests; start working on them after all functional, high priority, high value tests are implemented

Written by

Blogs about Selenium and Java at https://seleniumjava.com.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store