How to use Cypress App Actions?

Test automation is simulating user actions using a specialized automation tool. Creating a good test automation strategy improves the stability and performance of automation tests in your SDLC. The page object model is the most commonly used model while building the automation design strategy. 

Taking that into consideration, let’s look into the Cypress framework’s introduction to App actions strategy to perform automation.

What are App Actions in Cypress?

The app actions are, instead of interacting through the UI elements, directly dispatch the actions using the application’s internal logic. 

Advantages of Cypress App actions

• Faster compared to UI-based actions or Page object model
• More stable, as the tests are directly interacting with internal logic tests are more stable
• Reduced dependency of DOM elements. The DOM elements usually cause flaky tests or false positives whenever there are changes at the DOM level.

Limitation of Cypress App actions

• Requires understanding of internal code level knowledge
• Doesn’t simulate end-user interaction, and may fail to catch the UI level defects
• Calling too many actions too fast may result in unreliable results as the application may not be prepared to handle faster(unrealistic) interactions.

Automating Cypress Tests using App Actions

Let’s understand how to automate Cypress tests using the App actions pattern. As mentioned earlier the app actions have a lot of advantages however it has a limitation as well, the app action is a new concept that Cypress introduced to end-to-end testing.

For the demo purpose, we are using the MVC Todo Github repository code.

The MVC Todo app is a simple app, it adds the tasks to the to-do list, and as soon as you add the tasks it increases the to-do task counter.

Before moving to App actions, let’s consider the Cypress automation code in a Generic way without using App actions which help to understand the app action better.

Automate the simple scenario

1. Navigate to Todo App
2. Add the Todo task
3. Verify the todo count

Example code, without using App actions

describe('TodoMVC without App Actions', function () {
beforeEach(function () {
cy.visit('/')
})

it('should add task and verify the count',() => {
cy.get('input[class="new-todo"]').type("Explore Browserstack")
cy.get('input[class="new-todo"]').type('{Enter}')
cy.get('.todo-count').contains('1 item left')
})
})

In the above code, we are navigating to the application using cy.visit()

Using the cy.get() we are getting the locator for todo text box

The .type() command is used to type the Todo task and then use {Enter} to hit the [Enter] key.

The cy.get().contains() is used to validate the count after adding the task.

Once you execute the above test you can see the output below.

Example of Cypress App actions

Cypress allows interacting with the application under the test directly using the application logic. This makes the application testing faster and more stable as it bypasses the UI element interaction.

Rewrite the above Cypress test to use the App actions

Example of Cypress App actions

describe('TodoMVC with App Actions', function () {
beforeEach(function () {
cy.visit('/')
})

it('should add task and verify the count',() => {
cy.window().its('model').should('be.an','object').invoke('addTodo','Explore Browserstack')
cy.get('.todo-count').contains('1 item left')
})

The above code does exactly what the previous test is doing, it adds the new task and verifies the task counter. But it does everything by calling the internal logic. Let’s understand that.

The cy.window().its(‘model’) gets the underlying application object, once it gets the application object, you can call any underlying exposed logic or function. 

Cypress runs inside the browser and it can directly access the internals of your application. If you carefully observe the application code, We have exposed the application using the below code.

 if (window.Cypress) {
window.model = model
}

The .invoke(‘addTodo’) is used for calling the addTodo() function of the application which is responsible for adding the task. Using Cypress we can call directly. In the end, we are ensuring whether the counter value has increased.

Execute the code view results

• As you can see, the test result remains the same, only our approach is different. 
• The first one used a UI-based testing approach, and the last one used App actions.
• You can notice the major difference in execution time: the App action-based test took 737ms to complete and the Non-app action-based test took 1 sec to complete. 

This might not seem like a bigger difference, as we have only a simple test scenario with one use case; if you consider having hundreds of test cases with a complicated scenario, it can impact the test execution time.

Key Takeaways

Cypress App actions provide stable and faster tests and is worth considering. However, the major drawback is one needs to know the application’s internal logic. The QA team typically performs the end-to-end test automation; they don’t involve development. 

• Understanding internal logic may be difficult. Adding to this, App actions do not perform any actions using the UI, this bypasses the user actions, and any error which may occur due to user actions is not caught. 
• The end-to-end tests are written considering both the functionality and user interface, but the App action mostly concentrates on the functionality.

UI Testing is one of the critical parts of application testing where functionality alone cannot be considered for testing sign-off. While testing, the QA team needs to ensure the user interface and functionality are working seamlessly across the supported platforms and browsers to provide a smoother experience to the user. 

Run Cypress Tests on Real Devices