A Flexible Architecture for Automated Tests
Among the software projects developed by Bitlogic, Automated Testing occupies a major role. The Test Automation Strategy guarantees the quality of our software products and reduces test execution time.
In this article we want to share the Architecture of the Automated Tests we use, the technologies we chose and the advantages we encounter in these types of solutions.
The Tech Stack
Although there are multiple tools available to automate tests in Web Applications, we want to show you the ones we applied to build the architecture of a solution.
When choosing the technologies to be used in the project, we consider Open Source Tools to test new concepts and we also search for other tools that are flexible to send data to the other elements of the stack.
Selenium
We opt for Selenium as the tool to manage the Web browsers as a user would do, both locally and remotely, using a server. Its main characteristics and functionalities are:
- It’s an Open-source Software
- It works in multiple Operating Systems
- It supports multiple browsers
- It is run on Docker containers
- It uses Selenium Grid for distributing and running tests in parallel in remote environments
Python
Python is the language we adopt mainly because of its popularity among programmers. When people in the team have already acquired some knowledge in a programming language, their training needs are generally reduced.
Gherkin and Behave
In order to create readable Test Cases for the whole organization, they were written in Gherkin (a specific language of dominion) and its execution was made with Behave.
The Architecture of the Solution
To build the architecture, the solution was divided into four components:
- A Test Runner: A container, with minimum requirements, to run the tests remotely.
- A Grid: A container that distributes the execution of tests according to the selected browser.
- A Node: A container where remote tests are run.
- A Finder: A tool to search and create test data.
Official Docker images of Selenium were used for both the container that distributes Test Cases and the Nodes where tests are executed.
The Test Runner
This framework was designed using the POM pattern (POM stands for Page Object Model) that separates the logic of Tests from the logic to interact with the application using a page class that belongs to the application. For example, it is possible to create a class page for the Login page, another one for the Home page and so on for each app view. This model has two advantages: it avoids duplication of code (if the methods to interact with the elements within the pages were in the tests) and it reduces the maintenance of the framework by having one class per page separated into testing independent modules. A Base Class named “Page” was implemented as it contains generic methods to interact with Web pages and then, the classes that represent each page inherit it. As the tests framework evolves, so does the Base Class, as it is necessary to add generic methods that support new needs on the testing side. Having this "Page" with generic methods allows its reuse in future projects and saves implementation time.
A Tool to Search and Create Data
Finder was created as a microservice (API REST) packaged in a Docker image. In this way, a language-agnostic interface was achieved and the tool was used by diverse testing frameworks and by other quality solutions.
Finder consists of four modules:
- dbHandler: Module with the Oracle Database Client to execute known and verified queries. Its data output becomes the input that triggers the Testing search and data creation processes.
- dataCreator: Module with the "Python Request" library that generates test data by calling REST APIs of a legacy system.
- to webScrapper: Module that interacts with the legacy system applications using Selenium, injecting test data and collecting expected results.
- apiRest: Microservice with REST API exposed usingPython Flask library and documented with Swagger. As a microservice it is designed to support testing, its APIs represent project-specific business entities. Although it is useful to give support to tests in diverse applications it cannot be reused in future projects.
Conclusion
First, Automation Tests enable the disconnection of their executions and the team allocations. As they are built in the software pipeline, they can be run over and over again with each code change and thus having more accuracy when assessing the impact on the requirements. In addition, it allows the testing specialists to concentrate themselves in most valuable activities like the identification of new scenarios, the revision of defects with developers and a better understanding of the product.
On the other hand, when packing all these technologies in containers, the configurations are always the same. This fact makes tests more reproducible and their execution simpler along multiple environments. As a consequence, the general project costs are reduced and the quality of deliverables is easy to maintain.
In a forthcoming article we will show you the quantitative results of using this type of architecture for a Product Reengineering Process.
