Assertions and Retry | Bondar Academy
Course: Cypress UI Testing with JavaScript
Module: Interaction with Web Elements
Instructor: Artem Bondar
Lesson Summary
In this lesson, we explored Cypress assertions , focusing on their syntax and usage in testing. Here are the key points discussed: Types of Assertions Should Assertions : Can be chained directly from Cypress commands. Expect Assertions : Must be used within a then block. Syntax Examples For example, to check if a label contains the text "email address", you can use: cy.get('label').should('contain', 'email address'); Or with expect : cy.get('label').then(label => { expect(label).to.contain('email address'); }); Exact Matches For exact text matches, use: cy.get('label').should('have.text', 'email address'); Using Invoke When using invoke to get text, validate with: expect(text).to.equal('email address'); Available Assertions Refer to the Cypress documentation for a comprehensive list of assertions, including: Chai assertions: to.not.equal , to.exist , etc. Chai jQuery assertions for DOM properties. Retry Mechanism Cypress automatically retries assertions until the default timeout (4 seconds) is reached, ensuring stability in tests. Best Practices Not every element needs an assertion. Methods like cy.get and cy.contains inherently validate element visibility and presence. For more insights, refer to the Introduction to Cypress Guide for best practices on assertions.
Video Transcript
Hey guys, in this lesson we will talk about Cypress assertions. So we already used Cypress assertions in the previous lessons a little bit, but let's talk about it a little bit in details. Let's get into it. So for this example, and I created in your test, I'll go back to the previous lesson and grab this example as my starting point. So look, we made the validation right here that example, it would email one should contain email text. Let me copy and paste it right here. But Cypress also have a second type of syntax for the assertion, not only should assertion, but also expect assertion. You can use those types of the assertion if you would go, where is this second example? Let me copy this. So let's say if you using then, and you are inside of this then function, then in this example, if you want to make the same exact validation of the text for this label, you would call method expect like this, then the argument label, and then type to contain, and then provide a value that you expect like this, email address. And the syntax number one, this assertion and this assertion will do exactly the same thing. It's just different syntax. That's it. So here we use to contain, but if you use should assertion, you would use contain. So let's run this in action and you will see that it is working. Yeah, you see it's working as expected. The keyword contain is a partial assertion. If you want to make like exact match, you would have to use something like have text like this, and this one we need to update as well to have.text, email address, going back and look at this assertion pass. Now we have the exact match that this label should have text, email address. Let's take another example when we used invoke to get the text right here. Invoke to get the text, then email label, and then try to make assertion with the expect. So expect, and since this is already text, already is returned, then have text will not work. Because property have text kind of querying the web element and checking if the web element have text. But in our example, text is already here. So we just need to validate if this is the text that we are looking for. And I type just to equal and make a validation that this is the email address. And by the way, inside of the, then if you will use sci-wrap, remember this? Just in case, if you need this, and I take this email label. And now I can use should assertion, and use the same equal method, and the expected text is email address. Right here, and let's try if it is working. Yeah, all the assertions that we have created, pass successfully, and it is working. So when can you find the list of all available assertions? So the best resource is, of course, documentation. So you go under the references, into the assertion section, and here are the list of all available assertions. So first is the chai assertion, like to not equal, deep, instead, any, all, okay, true, false, exist, empty, and so on. And look, the syntax, they give you the exact syntax, how would you write if you would use should assertion, or if you would use expect syntax, depends on where you call the assertions. And the second type of the assertion is the chai jQuery. Chai jQuery are related to the DOM, if you need to invoke the DOM property. For example, get attribute property, CSS, class ID, invoke text, or value, should have value, should have text. To have text, and so on, and so forth. And Sin and Chai rarely used assertions with size tab and size pi. Later, we're gonna talk about it. Also, you can use VS Code IntelliSense, because it helps you to know what is available, what is not. So look, if I type single quotes, first I delete it, then I type single quotes, and VS Code showing me all available options. Look, it is a long, long list of possible assertions that I can use. So you can skim through this list and try to find the one that work for you. All right, so what else? One important concept that you should know about assertion is how it retries the web element to pass successfully. For example, when this assertion is invoked for this web element, at the time when assertion is executed, and if the, for example, email address is not there yet, Cypress will trigger method get to retry one more time and retrieve this ID from the web page to make sure that this element exists on the page, available, clickable, and so on. And then try to get this text one more time. And Cypress will try it until the timeout. So default timeout is four seconds. So Cypress will wait up to four seconds, doing its best as it can to get this value that you are expecting, making the validation, and then moving forward. So this retryability is actually very, very helpful and useful to keep your tests very stable. And also, I want you to look into this guide. So scroll all the way up, Introduction to Cypress Guide. And in this introduction also shows some of the tricks and best practices, how and when to use assertion. So first of all, you don't need to assert everything, to be honest, because Cypress has also a thing called implicit assertions. For example, methods like get or find, they expect element to eventually be available, visible, clickable in the DOM. Or if you would use CyContains method, you eventually validating that the text that you are looking for is available and visible to the user. So you technically do not need to make the assertion for the element that you found using CyContains. But keep in mind that don't use contains as your assertion method, because it's kind of incorrect. Contains is to find element by the text, not for the assertions. But if you're using CyContains, probably there is doesn't make much sense to add the assertions after that. And so on, so look into this article, it's pretty insightful about how to use assertions correctly and when to use them correctly. All right guys, so let's quickly summarize what we did in this lesson. So Cypress has two types of the assertions, should assertions and expect assertions. Should assertions can be chained directly from the Cypress methods like this. And expect assertions can be called only within then block. The list of available assertions you can find in the documentation or using VS Code IntelliSense and also Cypress assertions wait automatically to pass up to the default timeout. And about the timeouts, we're gonna talk in the next lesson. So see you in the next lesson.