There are many test tools available in the market that you can use for creating and running automated tests. But because there are so many, selecting one that fits your need and doesn’t let you run into problems due to badly readable and maintainable tests is hard. And when you have selected a tool, it’s important to setup your tests the right way. In this blog, I’ll cover four generic principles of good automated tests that can help you to make a better choice for tooling and the design of your tests.
Tests should be readable for non-IT people
Automated tests should be both readable and understandable for not just testers or developers, but for everybody. If people that are not working in a development team (stakeholders, subject matter experts) can also read and understand tests, you can use them to discuss requirements and discover if you understand each other correctly.
For tests to be readable for non-IT people, the format of the part that they read must be right. And with right I mean simple. That means that in order to read them, you should not have to know how to read source code or have technical knowledge. Preferably your tests should be written in plain text and with clear examples.
The specification should be separated from the implementation
Good automated tests consist of two parts: the specification that describes what we are testing, and the implementation that describes how we are testing. That means the specification describes the behavior (business rule or functionality) and the implementation contains all the steps necessary to automatically verify this behavior. This is the part that non-IT people will also see. The specification serves as living documentation of the requirements of your application.
Separating them allows you to write the specification part of the test before you’ve written a single line of code that actually implements the requested behavior. This makes it possible to do Acceptance Test Driven Development (ATDD), often also called Behavior Driven Development (BDD). You can elicit requirements early in the process and describe them in a clear way. The book “Specification by Example” by Gojko Adzic is a recommended read on this topic.
Tests should be described at the right level
Applications are all about behavior. When we test an application, we are testing the behavior of it. It should be clear for each automated test which behavior it is verifying. This is often a difference with manual test scripts, where for the sake of efficiency for the tester, we test multiple things at once for one function, area or screen of an application.
To make clear which behavior a test is checking, the specification part should be described at a high enough level. That means tests should be described on the level of business rules or functionality, not on the level of all the technical steps or user workflow needed to exercise that behavior. This is also a difference to manual test scripts, where all steps are described because we want the tester exactly to know what he must do to test a certain piece of functionality.
Since business rules often don’t change as much as for example the UI, your tests also will become more stable and easier to maintain. Gojko Adzic has a nice article that elaborates more on this topic: https://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/
The implementation should allow for re-use and abstractions
The implementation part of the tests contains all the steps to execute and verify the behavior under test. If you have a lot of duplication in this area across tests, changing the application can lead to many tests that also need to be changed to get them running again. This makes maintaining your tests harder and more expensive.
A good principle in software development is “Don’t repeat yourself” or DRY to get rid of duplication. To apply this in you tests, you should be able to re-use steps. It also helps if you can encapsulate steps into bigger chunks or abstractions that you can use. Re-use, encapsulation and creating abstractions is the core of programming. That’s why you often can or need to program the implementation part of the automated test.
These principles can help you select test tooling that supports creating solid and maintainable tests. Be aware that it’s not just about the tool: if you use it incorrectly and set up your tests the wrong way, you can still violate these principles. But if setup correctly, you can experience the full benefits of automated testing.
This blog was written by Harm Pauw.