Difference between Synchronous & Asynchronous Assertion Query Mechanism in Automation Testing

We have often heard about Synchronous & Asynchronous and why we should prefer JS base automation tools to automate the modern websites and applications that are based on JS based frameworks like React, Angular but only few knows how JS based automation tools really works in Automation testing. And we know why the latest JS based Automation frameworks like Cypress & TestCafe focused on that the Automation tests written in these frameworks are Asynchronous in nature.

Smart Assertion Query Mechanism

In synchronous functional testing, you can execute assertions immediately after test actions. while in Asynchronous functional testing you wait for the changes to occur i.e. wait for page to load etc. and then perform assertion

Functional tests are asynchronous on the web. This means that we cannot get the expected changes immediately after a user’s actions. For example, it can take time for the tested page to send a request to the server for the required data or a user’s action to invoke an animation after which the page reaches its final state. All these intervals cannot be pre-calculated because they depend on various factors: computer performance, network connection speed, etc. In this case, if we perform assertions immediately after the test action, we can get an inconclusive result.

As you can from above image that if we use synchronous assertions in our tests then they might fail here because the element on which we have applied assertion is dynamic and waiting for changes to occur in DOM due to which it is still not visible in DOM and that is why we often use waits in selenium to wait for that element to load, while in JS based automation frameworks it will automatically wait for the DOM to load and then apply assertion

An additional timeout is usually added when you perform asynchronous functional tests.

To stabilize asynchronous functional tests, you need to add a timeout that allows changes to be applied. Note that adding a timeout can increase the test’s duration.

Cypress & TestCafe uses the smart assertion query mechanism if the assertion receives a Selectors or DOM Node State property promise as an?actual?value: if an assertion did not pass, the test does not fail immediately. The assertion retries to pass multiple times, and each time it requests the?actual?property value. The test fails if the assertion could not complete successfully within a timeout:

let's see an example

Cypress is a JavaScript framework whose commands are asynchronous. After a test function finishes running, Cypress starts executing the commands that enqueued using the?"cy.*"?command chains. So ideally, the test mentioned above will execute in the following order:

1. Open the URL "https://www.someweb.com/"
2. Click on the button
3. Validate the number of items displays in table
4. Validate the number of rows in table.

From the test execution, it is clear to use that all these actions happen serially, so how come Cypress ensures for this serial execution even though it claims that all the Cypress commands are asynchronous. In actual there is magic happening beside the execution, using which Cypress ensures the serial execution of all these commands. Lets again revisit the above steps with the hidden commands that are executed by Cypress to ensure that the execution happens serially:

1.Open the URL “https://www.someweb.com/“.

• and wait for the?page load event?to fire after all external resources have loaded.

2.Click on the button

• and wait for the element to reach an actionable state or, in other words, a new page load event to fire.

3.Validate the number of items displays in table and same is for step 4 execution

• and retry until the assertion passes and command times out.

As?you can see, Cypress puts in lots of effort to ensure the state of the application matches what our commands expect about it. Any waiting or retrying that is necessary to ensure a step was successful must complete before the next phase begins. The test will fail if they don’t complete successfully before the timeout reaches.

In Cypress you don't need to define anything chaining is doing everything to ensure asynchronous nature of tests while in TestCafe we explicitly use async and await to define asynchronous nature of tests

Reference

1. https://testcafe.io/documentation/402837/guides/basic-guides/assert
2. https://www.toolsqa.com/cypress/cypress-asynchronous-nature/