DEV Community: Will Drygla

Missing Reports in Nightwatch with GGR + Selenoid

Will Drygla — Sat, 13 Sep 2025 18:53:18 +0000

Missing Reports in Nightwatch with GGR + Selenoid

Recently I noticed that in some cases, when running Nightwatch with GGR and Selenoid, some reports were missing. The test would reach the end, but at the reporting moment, the last one (sometimes the last 2 or 3) were not in the reports.

My investigation

I started my investigation by checking if unresolved promises during the tests could cause the process to be lost and not report, but soon I discovered that this was not the case.

I also investigated possible session-ending requests before the report arrived, but I found out that Nightwatch handles this well with its command queue — even if a promise is not awaited, the next command will only execute after the previous one finishes, so that wasn’t a problem either.

I tried forcing long calls in the after of each test, and even then Nightwatch handled it fine.

So I decided to go deeper and forked the repository, figured out how it worked, and started validating hypotheses until I finally found the issue.

I’ll make a summary here, but you can read it in full on the discussion:
👉 Nightwatch Issue #4416

What’s happening under the hood
The process of running tests in parallel creates several promises. Each promise is a child process, and inside each child process, during the end of the test suite, data is transmitted to the parent process through IPC messages. Then the test-end event is emitted, and the process ends.

The parent process, after all promises are resolved, moves on to the report stage.

The problem is that IPC messages don’t control delivery, only sending. This creates a race condition because:

The child process sends the IPC message
The child process emits the test-end event
All promises resolved → report step

What rarely happens is:

IPC message with test data is sent
Test-end event is emitted
Parent process moves to the report step since all promises are done
Report step collects the available data
Report is generated
IPC message content arrives afterward

Propose solution
Since there is no way to wait for the message to be delivered, I proposed a solution where the child process would send the message and wait for a response from the parent process confirming that the message was received.

Screenplay Pattern for Test automation: Actions - What an user can do

Will Drygla — Sun, 03 Aug 2025 12:20:33 +0000

🎬 Screenplay Pattern - Part 2: Actions
In the Screenplay pattern, once you've defined your actor, the next question is:
What can this actor do?

That's where Actions come in.

🛠️ What are Actions?
Actions are the building blocks of your test.
They define how an actor interacts with the system — but in a reusable and readable way.

Instead of spreading low-level commands all over your tests, you create named tasks that express intention, like:

   bankCustomer.makeAction('enterLoginCredentials', {
                email: validUser.email,
                password: validUser.password,
            });

It tells you exactly what’s happening — not how it’s implemented.

How the actions works:

I use an class for each feature of our system:

export class LoginActions {
    enterLoginCredentials(input: { email?: string; password?: string }) {
        loginPage.waitForPageToLoad();

        if (input.email) {
            cy.get(loginPage.getEmailInputSelector())
                .filter(':visible')
                .should('be.enabled')
                .clear()
                .type(input.email, { delay: 50 });
        }

        if (input.password) {
            cy.get(loginPage.getPasswordInputSelector())
                .filter(':visible')
                .should('be.enabled')
                .clear()
                .type(input.password, { delay: 50 });
        }
    }
}

The UI selectors are stored in a separate file. By keeping selectors in their own file, they can be reused across different actions.

After this, the actors who can perform this actions, only need:

export default class BankCustomer extends BaseActor {
    constructor() {
        const loginActions = new LoginActions();

        super(loginActions);
    }
}

So when you read a test and see an action, it tells you what is being done — not how it's done. If you want to check the implementation, just search for the action name or look it up in the documentation. (Screenplay makes documenting tests easier — more on that later!)

✅ Why use Actions?
Readable: Your test reads like a user story.

Reusable: One action can be used across many scenarios.

Maintainable: If the UI changes, you update the action, not every test.

In short:
Actions help you write tests that describe behavior, not code.
They're a key piece in making automation feel like a conversation between the user and the system.

Next post: ❓Questions – how do we verify what happened?

Screenplay Pattern for Test automation: Actors - Who uses our software

Will Drygla — Sun, 03 Aug 2025 12:08:13 +0000

🎭 Screenplay Pattern - Part 1: Actors
If you're diving into the Screenplay pattern for test automation, the first concept to understand is the Actor.

In Screenplay, actors represent the users or roles interacting with your application.
They don’t know how to do things — they just know what they want to achieve.

💡 Think of them like personas:

A customer logs in and transfers money.

An admin reviews reports.

A guest browses the site.

Why use Actors?
✅ Readable scripts:
Instead of reading raw implementation, you read intent:

bankCustomer.makeAction('enterLoginCredentials')

✅ Modular logic:
Actors separate who is performing actions from how they're done. It keeps your actions reusable and test logic clean.

✅ Test from the user's POV:
You shift focus from UI details to user goals. That helps both devs and stakeholders understand the test’s purpose.

How an actor works:

I use an base-actor, that have the methods to perform actions and questions:

interface IBaseActor {
    actions: ActionMethods;
    questions: QuestionMethods;
    /**
     *
     * @param action receives the name of a valid action for the actor
     * @param parameters this parameters will be passed to the action
     */
    makeAction(action: string, parameters?: any): void;
    /**
     *
     * @param question receives the name of a valid question for the actor
     * @param parameters this parameters will be passed to the question
     */
    makeQuestion(question: string, parameters?: any): void;
}

Then, I create the test users extending the base one, and pass to super, the available actions that the user can do ( next post will be about actions, but actions are separated by feature):

export default class BankCustomer extends BaseActor {
    constructor() {
        const loginActions = new LoginActions();
        const registrationActions = new RegistrationActions();
        const accountActions = new AccountActions();
        const transactionActions = new TransactionActions();

        const actionsInstances = [loginActions, registrationActions, accountActions, transactionActions];

        const loginQuestions = new LoginQuestions();
        const registrationQuestions = new RegistrationQuestions();
        const accountQuestions = new AccountQuestions();
        const transactionQuestions = new TransactionQuestions();
        const questionsInstances = [loginQuestions, registrationQuestions, accountQuestions, transactionQuestions];

        super(actionsInstances, questionsInstances);
    }
}

But, to this work, I had to make an proxy on the base-actor, because I'm passing to him actions and questions from different features, and I don't wanna do:

            bankCustomer.login.makeAction('clickLoginButton');

I wanna that all actions be available on the same level, not separated by feature ( for the actor, an action is an action, the separation by feature is only for code organization ), so, I do an proxy that make all works:

 constructor(actionsInstances: any[], questionsInstances: any[]) {
        this.actions = new Proxy(
            {},
            {
                get: (_, prop: string) => {
                    if (typeof prop !== 'string') {
                        return undefined;
                    }

                    for (const instance of actionsInstances) {
                        if (prop in instance) {
                            return instance[prop].bind(instance);
                        }
                    }
                    console.error(`Action ${prop} not found.`);
                },
            }
        );

With this, actors can access all its actions and questions only passing the action name.
Example of an test using actors:

 it('should successfully log in with valid credentials using BankCustomer actor', () => {
            cy.setLocalStorageUser({ email: validUser.email, password: validUser.password });
            const bankCustomer = new BankCustomer();

            bankCustomer.makeAction('enterLoginCredentials', {
                email: validUser.email,
                password: validUser.password,
            });

            bankCustomer.makeAction('clickLoginButton');

            bankCustomer.makeQuestion('isUserLoggedInSuccessfully');
        });

In short:
Actors are the core of Screenplay because they bring meaning to your tests. They make scripts readable, reusable, and realistic.

Next post: 🎬 Actions – what can an actor do?

How to create a test ecosystem

Will Drygla — Fri, 28 Feb 2025 15:38:04 +0000

As a QA Engineer, I have developed a robust test ecosystem that ensures the reliability and efficiency of our software. This ecosystem comprises multiple layers of testing, supported by shared libraries and exported modules. Below, I will explain the architecture, its components, and how they interact to maintain a high-quality standard in our software testing strategy.

The test ecosystem consists of four top-level testing strategies:

API Tests
Performance Tests
End-to-End (E2E) Tests
Manual Load Tests

These top-level tests leverage a set of shared libraries and exported modules to facilitate efficient test execution and data management.

Shared Libraries (LIBS)
These are essential utilities and tools that provide core functionalities:

QA-Utils: A collection of utilities for authentication, database connections, and entity management.
DB Operations: Handles database interactions including seeding and querying.
Massive Data Generator: Automates large-scale data generation for performance and load tests.

Exported Modules
These modules encapsulate specific functionalities and are consumed across different tests:

DB Operations - Seeder: Inserts test data into the database.
DB Operations - Queries: Validates and retrieves test data from the database.
QA-Utils - Entities: Defines data structures used across different tests.
QA-Utils - DB Connection: Manages the database connection as a singleton instance.
QA-Utils - Cognito Auth: Handles authentication using AWS Cognito.

Each type of test consumes specific modules based on its requirements.

API Tests

Utilize QA-Utils - Cognito Auth to validate user tokens.
Use DB Operations - Seeder to insert initial test data.
Leverage DB Operations - Queries to validate test results in the database.

Performance Tests

Utilize QA-Utils - Cognito Auth to validate user tokens.
Use Massive Data Generator to create initial test data for performance evaluation.

E2E Tests

Utilize QA-Utils - Cognito Auth to validate user tokens.
Use DB Operations - Seeder to create initial test data required for automated workflows.

Manual Load Tests

Use Massive Data Generator to create the necessary volume of test data to simulate real-world load conditions.

To streamline data creation and validation, the following internal dependencies exist:

Massive Data Generator relies on the Seeder module to insert bulk data efficiently.

Seeder consumes both DB Connection and Entities from QA-Utils to maintain consistency and reliability in test data setup.

Conclusion

This well-structured test ecosystem ensures that testing is automated, scalable, and efficient. By modularizing key functionalities and utilizing shared libraries, we achieve a seamless integration between different types of tests. This approach not only reduces redundancy but also enhances maintainability, making our software testing process robust and future-proof.

How to insert test context inside XML of jest

Will Drygla — Sun, 23 Feb 2025 16:48:20 +0000

Have you ever checked an XML of test reports, and think that could be more info inside it?

Today I will show you an way to insert test context inside the XML of jest (you could use any XML)

In my article:

Test context: A powerfull way to debug our tests

Will Drygla ・ Feb 23

#api #automation #codequality #testing

I talk about test context, now, we will put this context inside the XML.

I use this XML on my pipelines, after test runs.

Steps:

While test run:
1.1 - Collect test context
1.2 - Save context to a JSON file
When tests are finished
2.1 - Read the json file
2.2 - Read the XML file
2.3 - Find failures on XML
2.4 - Find an context the matchs XML failure (I match then based on test name)
2.5 - Write XML with the test context

Step 1:
afterEach(async () => { const { assertionCalls, numPassingAsserts, currentTestName } = expect.getState(); const failedTest = assertionCalls > numPassingAsserts; if (failedTest) { createContextJsonFile(currentTestName, testContext); } });

Step 2:
2.1: For each JSON on the 'reports' folder, whe call the function that save the data to XML report:
jsonFiles.forEach((file) => { const filePath = path.join(folderPath, file); fs.readFile(filePath, 'utf8', (err, data) => { const jsonData = JSON.parse(data); saveJsonToXml(jsonData)

2.4: Find an failure that match our JSON test name and write test context to it:

2.5: Write the XML with addition of new content:

fileContent = new XMLSerializer().serializeToString(doc); fs.writeFileSync(filePath, fileContent);

The result will be an XML like this:

Test context: A powerfull way to debug our tests

Will Drygla — Sun, 23 Feb 2025 16:24:30 +0000

In this post I will share with you guys an upgrade that I do to my API tests!

To test our system, I use system tests (integration / API / service) where I create a seed of data on database, then, make a request to an endpoint, and later check the results on the database.

The problem: When a test fails, on general, we don´t have much context about how things happened, and in general, we re run the tests locally to collect some info.

Also, this tests are great to be used when devs make big refactors that doesn´t change the application rules

My solution: I create on each test, a context variable, that, during test execution, is filled with Id's, responses, data from database, and, after the test execution, if the test failed, we add this data to the XML report.

How I do this:
Before the test:

Create a variable named testContext
Fill this variable with basic data from our Seed (the principal data the test handle)

During the test:

Collect API responses and save to the testContext
Collect data from database and save to the testContext before validations

After the test:

If the test fail, capture necessary info (test suite and name, failed reason) and add to testContext
Save the testContext as a JSON file

This helps our debug, since, when a test fail, we could check this JSON, to see if the initial data is correct, if API responses was OK and how the data was saved into the database, all this inside a JSON of 50 lines hahaha.
With a JSON like this, checking the logs, would be easy find the reason why it failed

I will give you an example of this JSON:

After this if the test is running on pipeline, we add the JSON inside the test XML (I will make an post only about the XML handle)

Using K6 to check the performance of our system

Will Drygla — Sun, 23 Feb 2025 15:58:57 +0000

Today, I come here to talk about a project I have been doing for the past few weeks. I was working with performance tests, and I wanna share how I am taking metrics out of my tests. My challenge was to identify endpoints that, when the system was loaded above normal, presented problems or excessive slowness.

I use Azure to run my tests, and export the results to Datadog (also export as XML to Azure, only to see basic info). The setup to run tests is simple:

Install K6, docker and other libs ( I use a custom AWS agent )
Configure the project and bundle
Start the Datadog docker ( who receives the data )
Run tests

And, in my configuration of scenarios in K6, I tag them to later I be able make custom dashboards, to extract data I use three tags:

Test run ID: to identify the test run in general
Scenario ID: separated by scenario, this could be the action that we are simulating or the screen we are simulating loads
Request ID: this has the name of the request

With these three tags, I created a custom dashboard with three tables, each one with data based on a tag, and also, general graphs ( timing, status code). Using these tables, we can analyze the results of each request, but also analyze the groups/actions/screen results. So, after this, it was only about running tests, increasing the number of users or iterations, and extract metrics from the dashboard.

Reading the graphs, we can extract some data:

Using requests per second + HTTP request duration: we can see the increase of the duration of requests as the number of requests gets bigger
Using requests per second + Status code: we can determine the number of requests per second that causes errors on the system
Using REQ_AVG_DURATION and REQ_MAX_DURATION: analyzing these two metrics allows us to assess both the typical performance and the stability of response times. A large gap between these metrics can indicate sporadic spikes or outliers, suggesting potential instability under certain conditions. Together, they help pinpoint whether performance issues are consistent or isolated, guiding us in optimizing both the average experience and managing worst-case scenarios. All this information must be analyzed alongside test duration, stage configurations, user loads, and other settings to gain a deeper understanding of system performance. This analysis allows us to identify areas for improvement or develop new hypotheses for further testing.

With these metrics, I was able to talk with our team and define a plan to improve these endpoints, to be more performative. I will let some prints of the dashboard ( the prints are individual of each graph). With three or four runs, you should be able to collect enough data to make a good presentation, or map some improvements.

My favorite K6 executors

Will Drygla — Sun, 23 Feb 2025 15:55:56 +0000

Today, it’s a beautiful day for me, raining, cold and I’m off work, so, I decided to make a 'chimarrão' and study a little bit, and I choose a great theme, k6 scenarios executors!

When we define scenarios in the k6 options, we can define the executor, and, with a brief reading about them, I wasn’t able to understand much, so I decided to do my best, and create a mind map with the basics about them.

With the mind map, I achieve a better understanding of each one, and i decided to share two of them with you guys:

constant-vus
This executor is simple and really useful, it makes constant iterations based on the number of VUs and duration that we configured. This is great to simulate a number of users making the same action at the same time. In real life, we could use this to test a stock trading system, and check how the system handles the amount of users buying or selling stocks at the same time.
ramping-arrival-rate
This executor starts on a rate ( rate of interactions / time ) and for each stage it updates the rate based on what we configure. This is really useful, like, we could use this to make tests of system capacity, but instead of simulate a number of users using the system, we configure the number of iterations on each time, for example, we could define a start in 10 iterations per second and ramp up to 100 iterations per second, and see how the system handle it. In real life, we could use this to test an e-commerce system, simulating a slow start of sales, then, a ramp up simulates a lot of users buying at the same time, and after, ramp down.

I'm really excited about studying performance testing and k6 (I already have some experience with JMeter). It's great to learn how we can use these tests to ensure a system meets user needs and stakeholder expectations, while also confirming that the system can handle potential high usage or load.

Uploading screenshots to Azure tests

Will Drygla — Sun, 23 Feb 2025 15:52:10 +0000

I wanna share a solution that I have developed to improve my debugging with Cypress and Azure. Cypress takes screenshots of test failures, which give us a lot of context about the failure, but, I didn’t find a way to visualize these screenshots with Azure. So, I looked over the internet and found some articles, I took this as a base, and developed a custom solution. I will bring here step-by-step how I do it.

Basically:

Grab all Cypress screenshots and simplify they name
Get all test runs for that release
Then Get all failed tests to that release
For each test find a matching screenshot and upload it Let's see:

1- We need to get all screenshots and save its path on a variable to use later, here, comes our first problem, depending of how the test fails, the screenshot name changes, appears a 'before each', 'after each', to make this work, I made a function to simplify the name, it receives the full path, remove unnecessary data, and save to a pathMap, then, after we use the same function to simplify the test case name and look for a match:

function simplifyName(filename: string): string { return filename .replace(/ --/g, '') .replace(/"/g, '') .replace(/ $failed$\.png/g, '') .replace(/before each hook/g, '') .replace(/after each hook/g, '') .replace(/for/g, '') .replace(/ /g, ''); }

async function collectPngFiles(directory: string, pathMap: Map<string, string>): Promise<void> { const entries = await fs.readdir(directory, { withFileTypes: true }); for (const entry of entries) { const fullPath = path.join(directory, entry.name); if (entry.isDirectory()) { await collectPngFiles(fullPath, pathMap); } else if (entry.isFile() && entry.name.endsWith('.png')) { const simplifiedName = simplifyName(entry.name); pathMap.set(simplifiedName, fullPath); } } }

These two functions save the simplified name and its corresponding full path to a variable pathMap.

2- Now, we need to get all failed tests on the release of Azure. To this, I make a get on Azure, that returns all test runs from that release, with that in hand, for each test run, I make a new get, but this time, only searching for failed tests. Then, for each failed test, I apply the same algorithm to simplify its name, then we need to check if there is a screenshot who matches the test case name on the pathMap .

3- When we find a match, between the screenshots taken by Cypress and failed tests on Azure, we need to upload it to Azure on that test run, to be available to check on azure:

if (screenshotPath) { const screenshotFilenameWithoutPath = path.basename(screenshotPath); const createTestResultsAttachmentUrl = ${teamFoundationCollectionUri}${teamProjectId}/_apis/test/runs/${testRun.id}/results/${testResultId}/attachments?api-version=5.1-preview.1; const base64string = await fs.readFile(screenshotPath, { encoding: 'base64' }); const jsonBody = { fileName: screenshotFilenameWithoutPath, comment: 'Attaching screenshot', attachmentType: 'GeneralAttachment', stream: base64string }; const response = await axios.post(createTestResultsAttachmentUrl, jsonBody, { headers: { Authorization: Basic ${btoa(:${personalAccessToken})}, 'Content-Type': 'application/json' } });

Then we only need to deal with Azure response.

This is a Typescript script, that is the same of the tests, it runs after tests on Azure. I made this a few months ago, and this is really helping me debug, since I don’t need to run the test locally again to see what is wrong, the context given by the screenshots really helps the understanding.

I hope it helps somebody with a similar problem!

Screenplay: another way to think about e2e tests

Will Drygla — Sun, 19 Jan 2025 23:10:58 +0000

Lately I have been looking for alternatives for the 'commum' way of writing automated tests, the automated tests code in my view, care too much with code, and little with behavior.

To change this, I found the Screenplay pattern, where, basically, we will write test code thinking on behavior, results, and the code will only be a tool to this.

The Screenplay focus on Actors, this Actors have Abilities, make Actions and asks Questions, with this, we can abstract our code to be outside the test.

I implemented the Screenplay pattern on Cypress and Typescript like this, for a software of warehouse management:

Let's imaginate a warehouse management system, in this system, we have two types of users, the managers and the workers.
The workers, receive new products, make purchase orders and label new products, the managers, approve purchase orders, generate reportes and more.
Let's see how can we automate the tests for this software using Screenplay

PS: I will simplify the code for a better understanding

Actors:

1. I use a base-actor:

in the base-actor has a constructor, that receives a list of actions and questions
there is the methods makeAction and makeQuestion

2. Each user of tests extends this base-actor passing to him necessary Actions and Questions:


actors/warehouseManager.ts
    WarehouseManager{ 
        actions: 
            approvePurchaseOrder,
            generateReports,
            planShipments,
            assignTasks,
            createProducts
        questions:
            wasPurchaseOrderApproved,
            wasReportGenerated,
            wasShipmentPlanned
            wasTaskAssigned,
            wasProductCreated
    }
actors/warehouseWorker.ts
     WarehouseWorker{ 
        actions: 
            makePurchaseOrder,
            receivesDeliveries,
            generateProductLabels
        questions:
            wasPurchaseOrderGenerated,
            wasDeliveryReceived,
            wasProductLabelsGenerated
    }

2. Actions:

- Actor make Action to interact with the system

- I divide Actions based on features

- Actions can receive parameters

- Actions describe a behavior of user on the feature


actions/purchaseOrder.ts
    purchaseOrderActions{
        makePurchaseOrder(input: NewPurchaseOrderInput){
            cy.get('#btn-new-purchase-order').click()
            for(const item of input.items){
                cy.get('#order-new-item').click()
                cy.get('#input-search-items').type(item)
                cy.get('#select-option').contain(item)
            }
            ...continues
        }
        approvePurchaseOrder(input: ApprovePurchaseOrderInput){
            cy.get(`#purchase-order-${input.orderId}`)
            cy.get('#btn-approve-order').click()
        }
    }
actions/products.ts
    productActions{
        createProducts(input: NewProductInput){
            cy.get('#btn-new-product').click()
            cy.get('#input-product-name').type(input.productName)
            ...continues
        }
        generateProductLabels(input: GenerateProductLabelInput){
            cy.get('#btn-generate-product-label').click()
            cy.get('#select-label-type').click()
            cy.get(`#option-${input.labelType}`).click()
            for(const product of input.products){
                cy.get('#select-products').click()
                cy.get(`#option-${product}`).click()
            }
            ...continues
        }
    }

3. Questions:

- Actor make Questions to validate system state

- Questions are also based on features

- Questions can receive parameters

- A Question is a 'expected' on the end of code


questions/purchaseOrder.ts
    purchaseOrderQuestions{
        wasPurchaseOrderApproved(input: WasPurchasedOrderApprovedInput){
            cy.get(`#orders-li-${input.orderId}).click()
            cy.get('#order-status').should('be.eql', input.expectedStatus);
        }
        wasPurchaseOrderGenerated(input: WasPurchaseOrderGeneratedInput){
            cy.get(`#orders-li-${input.orderId}).should('be.visible')
        }
    }
questions/products.ts
    productQuestions{
        wasProductCreated(input: WasProductCreatedInput){
            cy.get('#li-products').should('contain', input.productName)
            ...continues
        }
        wasProductLabelsGenerated(input: WasProductLabelsGeneratedInput){
            cy.get('#btn-product-labels').click()
            for(const product of input.products){
                cy.get(#li-product).should('contain', product)
            }
            ...continues
        }
    }

With this design it's easy to write test code

For example:


e2e/cypress/purchaseOrders/approvePurchaseOrder.ts
describe('approval of purchase orders', () => {
    beforeEach(() => {
        const databaseAdministrator = new DatabaseAdministrator();
        databaseAdministrator.makeAction('generateData', seed);
    })
    it('warehouse manager should approve a purchase order that is pending', () =>{
        warehouseManager = new WarehouseManager()
        warehouseManager.makeAction('visitScreen', 'orders');
        warehouseManager.makeAction('approvePurchaseOrder', 'new-order-01');
        warehouseManager.makeQuestion('wasPurchaseOrderApproved', 'new-order-01')
    })
})
e2e/cypress/products/generateProductLabels.ts
describe('generate product labels', () => {
    beforeEach(() => {
        ...handle test preparation
    })
    it('warehouse worker should generate product labels', () =>{
        warehouseWorker = new WarehouseWorker()
        warehouseWorker.makeAction('visitScreen', 'products');
        warehouseWorker.makeAction('generateProductLabels', ['item-01', 'item-19', 'item-2523']);
        warehouseWorker.makeQuestion('wasProductLabelsGenerated',  ['item-01', 'item-19', 'item-2523'])
    })
})

remember, the code it's simplified to better understanding, real code need more details

Key Points:

1. With this pattern, we create tests that are easy to understand and maintain.

Tests written in the screenplay pattern use a structured, human-readable format, reducing the learning curve for new team members.
The separation of concerns in this pattern minimizes redundancy and simplifies updates when the system changes.

2. Writing frontend code with good test identifiers facilitates the creation of automated tests.

Well-named selectors and identifiers make it easier to map test steps to system functionality, improving readability.
By merely reviewing the Actions in the tests, stakeholders can grasp how the system behaves without needing in-depth technical knowledge.

3. Instead of using Cypress env to manage commands, we use Classes, like common code.

This approach aligns test code structure with the development team's patterns, fostering consistency across the project.
Using classes promotes reusability and makes the test code more modular and scalable.

4. Inside Actions, there could be other commands, like 'selectOption' or 'visitScreen'.

For smaller, reusable commands, Cypress.Commands.add is a practical choice to encapsulate these behaviors.
This ensures that the primary logic in Actions remains clean and focused, while Cypress env handles auxiliary functionalities.

Understanding Performance Testing: A Guide to Testing System Capacity

Will Drygla — Sun, 20 Oct 2024 12:11:04 +0000

Helloo, today, I decided to talk a little bit about performance tests. In the last few days I have been working with performance tests, and I’d like to share how I approach these tests to ensure system performance.

While it may be tempting to overload the system just to see how it handles failure, it is crucial to gather meaningful metrics during testing.

Performance testing can vary significantly depending on the specific goals and expectations set by the company. In this article, I’ll focus on a few scenarios aimed at evaluating the system’s capacity.

I start identifying the baseNumberOfUsers, let’s say we are testing a system of a bank agency, that uses the same system for all users, let’s divide the users into three types: Operators, ATM users and APP users, so, imagine that the agency has 10 ATM’s and 30 Operators, with a average number of users in the app of 50.

We could say that the baseNumberOfAtmUsers is 1, baseNumberOfOperators is 3, and baseNumberOfAppUsers is 5.

And I use a variable to set the scalability, which I’ll call scalabilityMultiplier. The scalabilityMultiplier allows me to scale the number of users proportionally, simulating different levels of system load

For the scenarios, I am writing three for each type of user, in general, two simple and one more complex, for example, let's write the scenarios for the ATM user:

One: Withdrawing money ( 4 GET requests + 3 POST requests );
Two: Transferring money ( 4 GET requests + 3 POST requests );
Three: Performing a deposit, payment, and withdrawal ( 12 GET requests + 6 POST requests );

Now, we can test our system and take some metrics of it.

appUsers = baseNumberOfAppUsers * scalabilityMultiplier

operators = baseNumberOfOperators * scalabilityMultiplier

atmUsers= baseNumberOfAtmUsers * scalabilityMultiplier

We begin by testing with one-third of the total users and gradually ramp up to the maximum.

Let’s get two metrics I use:

percentageOfSuccess
avgReqDuration

With this, we could test the limits, checking both, like, even if the percentageOfSuccess remains above 99.9%, a high avgReqDuration indicates the system is reaching its performance limits at that particular user load.