Here you can find a video recording from a talk dedicated to the ideas from my book “Design Patterns for High-Quality Automated Tests: Clean Code for Bulletproof Tests”. I presented key concepts such as how to optimize and stabilize your flaky tests, improve the test readability, maintainability, reusability, extensibility through many design patterns, principles, and best practices. Also, you can find below the video more information about the high-quality test attributes and links to related articles.
High-Quality Test Attributes
The time has come to define the automated test’s high-quality attributes. You will find that some of these attributes are connected to the SOLID principles and throughout the book, we will continue to talk about these connections. Вe will first go through these definitions, and then we will go briefly though each of the high-quality attributes.
What Is a Design Pattern?
We can define the design patterns as prescribed solutions to everyday software challenges. They don’t consist of code or any specified algorithm, but instead, they describe how to group your logic smartly, reuse it, or to make it easier to maintain. It is a template for solving design problems, which we can use while we create our software solutions.
Test Maintainability and Reusability
Definition: Maintainability
The ease with which we can customize or change our software solution to accommodate new requirements, fix problems, improve performance.
Imagine there is a problem in your tests. How much time do you need to figure out where the problem is? Is it an automation bug or an issue in the system under test? In the next chapters, we will talk in detail about how to create maintainable tests using various practices and design patterns. But if at the beginning, you haven’t designed your code in such a way, the changes may need to be applied to multiple places which can lead to missing some of them and thus resulting in more bugs. The better the maintainability is, the easier it is for us to support our existing code, accommodate new requirements, or just to fix some bugs.
A closely related principle to this definition is the so-called DRY principle- Don’t Repeat Yourself. The most basic idea behind the DRY principle is to reduce long-term maintenance costs by removing all unnecessary duplication.
Test Readability
By reading the code, you should be able to find out what the code does easily. A code that is not readable usually requires more time to read, maintain, understand and can increase the chance to introduce bugs. Some programmers use huge comments instead of writing more simple readable code. It is much easier to name your variables, methods, classes correctly, instead of relying on these comments. Also, as the time goes by, the comments are rarely updated, and they can mislead the readers.
API Usability
As we mentioned above, the API is the specification of what you can do with a software library. When we use the term usability together with the term API, it means “How easy it is for you as a user to find out what the methods do and how to use them?”. In the case of a Test Library - “How much time a new user needs to create a new test?”
In the programming community, we sometimes use another term for the same thing called syntactic sugar. It describes how easy it is to use or read some expressions. It sweetens the programming languages for humans. The programming statements become more concise and clearer.
Extensibility
One of the hardest things to develop is to allow these generic frameworks to be extensible and customizable. The whole point of creating a shared library is to be used by multiple teams across the company. However, the different teams work in a different context. So, the library code may not be working out of the box for them. In order to use your library in all these various scenarios, that you cannot (and shouldn’t) consider while developing it, the engineers should be able to customize some parts of it to fit their needs.
In the case of automated tests, imagine that you have a test suite testing a shopping cart. The workflow of the test consists of multiple steps- choosing the product, changing the quantity, adding more products, applying discount coupons, filling billing info, providing payment info and so on. If a new requirement comes - “The billing info should be prefilled for logged users.”, how easy would it be to change the existing tests? Did you write your tests in a way that, if you add this new functionality, it will not affect the majority of your existing tests?
Learning Curve
I also like to call this attribute “Easy Knowledge Transfer”. The attribute answers to the question “How easy is it for someone to learn how to add new or maintain the existing tests by himself?”.
The learning curve is tightly coupled to the API usability, but at the same time it means something a bit different. If a new member joins your team, is he able to learn by himself how to use your test automation framework or he needs to read the documentation if it exists? Or you have a mentoring program where you need to teach these new members yourself every time how to use your code? To the end of the book, I will show you how to develop your test automation code in such a way that the new members will be able to learn how to use your solution by themselves.
Defining High-Quality Test Attributes for Automated Tests
WebDriver – Capture and Modify HTTP Traffic – Java Code
Generic Repository Design Pattern- Test Data Preparation
Black Hole Proxy Pattern for Reducing Test Instability
Related Articles
Page Object Pattern in Automated Testing Java Code
Advanced Page Object Pattern in Automated Testing Java Code
Facade Design Pattern in Automated Testing Java Code
Strategy Design Pattern in Automated Testing Java Code
Decorator Design Pattern in Automated Testing Java Code
Advanced Strategy Design Pattern in Automated Testing Java Code
Fluent Page Object Pattern in Automated Testing Java Code
