Alex Siminiuc
Oct 12 · 4 min read

What Are Test Automation Good Practices?

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

Alex Siminiuc

Blogs about Selenium and Java at

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade