Building E2E automation the right way: A guide for engineers
In the rapid world of software development, automation has become a necessity, not just a luxury. But how do we navigate the vast array of automation tools and best practices to create the right system for our team? This blog explores the fundamental principles of building robust and impactful end-to-end automation, making sure your tests work for us, not against us.
In the past, I have worked on various automation processes — from scenarios with no automation, trusting developers for validation, to making automation a necessity for all features. The latter would prevent developers from pushing changes to the production environment without proper checks.
Here’s a brief reminder about automation and its purpose. A common misconception is that automation will always catch and prevent all bugs from reaching production. However, automation only covers what it’s specifically programmed to test. New components and features won’t be covered until tests are written for them.
Types of automation
There are three main types of automation we aim to establish at Melio: unit test automation (component test), integration test automation, and end-to-end (E2E) automation.
Unit testing:
This is the first level of testing conducted by developers. It validates and ensures that new functions are working correctly and are capable of throwing errors when needed.
Integration test:
This refers to testing the service as a whole. This means we will initiate the service and primarily test it with all open APIs while mocking all external responses. The aim is to ensure correct behavior and prevent unwanted flows.
E2E test:
The most resource-intensive testing occurs when we test an environment such as development, stage, or production. This involves ensuring all services are up and running and testing user flows. Because these tests are costly in terms of time and infrastructure, it’s essential to remember what could be covered in earlier testing stages. We should focus primarily on positive user flows.
E2E infrastructure overview:
There are primarily two locations for your End-to-End (E2E) automation: it can either reside in the developer’s repository, which allows for close contact with the developers’ changes, or it can exist as a standalone repository, which requires constant monitoring for any changes to prevent breakage. The specific location of the Automation repository is a topic for another blog and won’t be addressed here.
For now, let’s focus on building the infrastructure for end-to-end (E2E) automation. While I won’t delve into the various modules we can assist with, I will cover the essential building blocks.
The choice of language for automation testing can vary, as automation exists in every advanced language. But my experience suggests that it’s best to align the automation language with what is commonly used by your company, especially within your team or group.
E2E Automation: Building blocks for success
Infrastructure block:
In the basic infrastructure of the automation, we aim to build the first phase as basic as possible to enable future module replacement. It’s essential to consider this at every step of the process.
- First Level — The first aspect to consider is the testing module you plan to use. Ensure the testing module can run in parallel and adequately meets your needs in terms of language, documentation, etc.
- Second level — It’s crucial to select the appropriate report for your needs and integrate it with your upcoming infrastructure. You might even consider encapsulating the report to facilitate future replacements.
- Third level — Make sure to include an API level. This requires setting up the module you are using and wrapping its functionality. It’s beneficial to add an API module yourself as it can be used in various scenarios, such as triggering a test step or accelerating flows in your testing.
- Fourth level — If you are using the automation UI, you will need to set up the basic functionality of the module you are using, such as finding elements, clicking, hovering, get/set text and other basics.
- Fifth level — we want to integrate an assertion/validation module, encapsulating it within our reporter for comprehensive use across all our testing scenarios. This step ensures the exclusion of any other assertions by developers. This strict control over assertions is vital as it significantly enhances the reporting mechanism, offering the clearest insights into the reasons behind failures, thereby maximizing the comprehensibility of the reports.
Pages/business areas block:
In this setup, we’re establishing a dedicated folder to house all the pages under development. This approach emphasizes the distribution of pages, which holds more significance in UI testing.
I strongly advise adopting this structure as your primary distribution method. It offers a systematic organization of functionalities based on the end user’s perspective, allowing you to align your testing strategies accordingly.
Consolidating all functionalities for each page/area using an Infrastructure block streamlines method creation and implementation within the specific context, ensuring focused and organized development.
Testing block:
In this folder, our goal is to simplify the writing process significantly. Each section will be organized by distinct functional testing aspects. Every test within these sections will utilize the Pages block to navigate through the intended test scenarios. The choice of conducting assertion and validation can be either from the Infrastructure block or within the Pages block, based on your preference. However, I suggest retaining it within the Infrastructure block rather than pre-writing all validations.
Summary:
Starting with the understanding that there’s no one-size-fits-all approach to constructing the ideal automation infrastructure, this blog acknowledges the diversity in needs, available resources, expertise, and team dynamics. It encourages tailoring the approach while retaining fundamental principles.
Diving into the development of robust end-to-end (E2E) automation, this blog prioritizes the strategic setup of infrastructure, organizational strategies, and fundamental principles. It briefly covers unit testing, integration testing, and extensively explores E2E testing, providing valuable insights into structuring E2E automation infrastructure.
With a focus on vital automation principles and foundational building blocks, the blog aims to guide in optimizing testing blocks for efficient and impactful automation processes
Hope you enjoyed reading this, and good luck with your code.
