Explaining Assertions
The validation steps determining whether the automated test case’s specified step succeeded are assertions. Assertions generally validate the desired state of your elements, objects, or application under test.
Assertions logic in Cypress.
Cypress’s commands automation differs from other testing tools due to its assertions feature in Cypress. They will look “downstream” at your expression and adjust their behavior to make your assertions pass.
Assertions in Cypress are used to check the state and behavior of elements in a web application during testing. The assertion also allows developers to verify that the expected behavior of a web application is occurring and to catch any unexpected behavior.
Default Assertions
Cypress provides several built-in assertions that can be used to check different aspects of a web application, such as whether an element is visible, contains certain text, or has a specific CSS class. Some examples of Cypress assertions are:
- cy.visit(): every-time you visit a page, Cypress expects the page to return with a 200 status code
- cy.get(): the get command expects the element to exist in the DOM first before trying to access it
- .should(‘be.visible’): Checks that an element is visible on the page
- .should(‘have.text’, ‘some text’): Checks that an element contains a specific text
- .should(‘have.class’, ‘class-name’): Checks that an element has a specific CSS class
Custom Assertions
Developers can also create custom assertions using the Cypress expect() function. This function can assert any value, not just DOM elements. For example, developers can use expect() to check the value of a variable or the response from a network request.
Assertions in Cypress are typically chained onto a command that targets a specific element or performs a specific action, such as clicking a button or filling out a form. This allows developers to easily verify that the correct behavior occurs in response to the action.
Overall, assertions are a crucial aspect of testing with Cypress, as they enable developers to ensure that a web application behaves as expected and catches any unexpected behavior.
Implicit & explicit assertions
Implicit and explicit assertions are two types of assertions that can be used in testing with Cypress.
Implicit assertions are built-in assertions that are automatically added to most Cypress commands. These assertions are designed to ensure that the application under test has loaded and is ready for testing. For example, when a cy.visit() command is executed, Cypress automatically waits for the page to load and become interactive before moving on to the next command. This means that an implicit assertion is being made that the page has loaded successfully before proceeding with further testing.
Explicit assertions, on the other hand, are assertions that are explicitly defined by the developer using the should() command. These assertions are used to check specific elements or behaviors of the application under test. For example, a developer may use an explicit assertion to check that a button on the page is disabled after it has been clicked.
While implicit assertions are useful for ensuring that the application under test is ready for testing, explicit assertions are essential for verifying that the expected behavior of the application is occurring. By explicitly defining assertions, developers can catch any unexpected behavior that implicit assertions may not have covered.
Key Benefits
- It provides better observability into the design and helps easier debug test failures.
- Another benefit is its utilization in formal verification of the design and for the dynamic simulations.
- Provide functional coverage on input stimulus and validate that a design property is simulated.
- Help testers decide on specific parts of the code, which are guaranteed to return specific, error-free results.
