A clean test-automation framework is a challenging task. I want to share a few tips I have learned from my mistakes to build an effective framework.
The test-automation framework projects can get really messy extremely fast especially when a big team working on it. I will try to give common mistakes and tips to build a clean and effective framework.
We will focus on three main concepts:
- Simplicity
- Team oriented
- Maintainance activities should be a ticket
Examples based on below technologies:
Java
Selenium WebDriver
Junit/TestNG
Cucumber
Maven
Simplicity. The most important idea to keep the test-automation project effective is to design it as simple as possible. Any test automation engineer by looking into your project for 5 min should be able to figure out the main components and mechanisms of the framework.
It’s easy to say make it simple, but how to achieve it, this is the question. Let’s start with a few bullet points
- Do not wrap libraries and change their API names. Usually, it’s done by tech leads or the main framework maintainers. I have seen these kinds of frameworks a number of times. It creates a big mess. Especially if they will try to force you to use these wrapper classes. Usually, people wrap the Selenium WebDriver by trying to make it more generic and adding waiting time or handling things via JS executor. Everyone knows how does Selenium WebDeriver works, but none custom wrapper classes. You can find all possible information about Selenium on the web and for specific wrapper classes not. Usually, for this kind of wrapper class, there is no clear documentation and defects are present. I think libraries are already enough generic and not need to wrap it and create confusion.
- Do not add extra layers to the automation script. This is my personal opinion. For example, when we use Cucumber BDD. There are three main components of cucumber - feature files, step definition implementations, and runner class. So in the step definition classes, the automation code should go directly without any extra layers I saw examples where there is one abstraction layer. I really think it’s extra work creating this layer and we need to write test automation code directly into step definition methods. I think we can create an abstract layer in a specific component. For example, if we have database testing, or we need to work with a file system — to establish connections and main manipulations can be done via abstraction.
- Pay attention to the pom.xml file. The pom.xml file is a central file that manages dependencies and various plugins. It’s very important to keep the pom.xml file short and get only the required dependencies and plugins.
- One test-automation framework(project) for one application. Do not reuse a single project for two, not related applications.
Team oriented. While adding a new tool or changing an existing one or designing some reusable component, always think about your team. The main question — can they adopt it? It does not matter how cool is a new tool(library) or how great is your reusable component if your team cannot adopt it then there is no point in doing it.
Documentation. Every mechanism of the framework should be well documented and your team should be aware of these documentations.
Another good point of an effective framework is the setup process. let’s say a new hire joined your team. Assuming he has all the required software and access, now it’s time to set up the project locally. How long it will take him? Can he do it by himself? Ideally, it should be cloning the repository and the project should be ready to go. All credentials, browser drivers, and all other stuff should be already handled. If we cannot avoid some setup process, the step-by-step short videos would be the best option to provide.
Maintainance activities and refactoring should be a ticket on your board. it is like with a house, in order to keep it clean all the time we need to maintain a clean environment and just clean by little consistently. If we will wait till it gets messy and clean after, most of the time it will be messy, and only a few days after cleaning it will stay clean.
So the maintenance and refactoring activities should a ticket on your board every sprint and we need to do it consistently.
That is it for a clean test-automation framework. Please share in the comments what worked for you or what kind of mistakes we should avoid. Thank you for reading!
