3 Tips to execute your test in parallel
In this article, I will share 3 tips that can help you to execute your test in parallel.
What is parallel testing?
Parallel testing is a process that allows you to run your tests at the same time to reduce the execution time.
For example, if you have 120 tests that need around 30 minutes to run sequentially in Firefox, WebKit, and Safari. You can set up your test to run in parallel with 3 agents. And you can run 3 different tests at the same time. So, instead of waiting 30 minutes, you can get the results in around 10 minutes.
You must prepare your automation testing to follow some guidelines to execute your test simultaneously.
It would help if you executed your tests:
Without dependencies.
In any order.
It should be run quickly.
These are 3 tips to help prepare your test to run in parallel. The samples are in Playwright, but using the same ideas for Cypress or webdriverIO should be easy.
1 Auto generate to test data.
The test must use different data, or you can have some duplicated info if the test is executed simultaneously in various browsers.
You could find some interesting bugs if your test uses different data each time it is executed. In an e-commerce test, I changed the test to instead of always testing with the same item, I select a random item, and one time I saw a Lorem ipsum item on the production page, too the automation test found bugs due to some restrictions to the items: some items were available only for some cities. I also changed the user data to valid directions; sometimes, I changed the valid directions for others.
One option that I use is Fakerjs. This library allows you to generate random data for different categories of data like usernames, cities, lorem ipsum texts, etc.
Install fake with the following command.
npm install @faker-js/faker --save-dev
In your test spec file, add the import to Faker.
import { test } from '@playwright/test';
import { faker } from '@faker-js/faker';
test('Create a employee', async ({ page }) => {
const name = ffaker.person.firstName();
2 Use API to generate pre-conditions data and clean data
Your test should test only one flow, and you can use API to generate pre-conditions data instead of doing so by the UI or running your test in a specific order: create employee and after in the edit employee test, use the previously created employee if for some reason the create employee test fails you can't run the edit employee.
So you can use API in edit employee test to:
Create an employee
Use this employee to edit
Test the edit works correctly
Delete the employee with the API
With this, you will reduce the time needed for the test, and you are testing only one function.
Another example is e-commerce; you can clean the items in your shopping cart by API before your test starts to check items in the shopping cart instead of adding steps in the UI to clean in each test related to buying an item. And you can add one test to check if the user can remove items from the cart.
3 Write small and fastest tests
Instead of testing very complex and large user flows, splitting them into tests that test one part of the complex flow is essential. With this, you can easily detect the exact step with the bug.
Finally, you must run your test in parallel and need good hardware, like a processor or memory; otherwise, your test will fail randomly with timeouts.
Some options that the Playwright provides are:
Microsoft Playwright Testing: It's in preview and is free for 100 minutes. You can simultaneously run your test in the cloud with different operating system combinations. This video explains how:
Sharding tests: Execute your test in different machines and, in the end, merge all reports in one file.
In my playwright boilerplate framework, I added the sample to sharding tests: