00:00 To cover this new use case in tests, let's reproduce it first. So here I render the discount code form. Next, let's get our discount input. Get, so page get by label text, discount code. Let's enter some value.

00:17 So fill our discount code, Epic 2025. Next, let's get the apply discount button by its role, get by role button and accessible name that says apply discount and click on it to apply it.

00:37 Next, let's create a variable where we will store the locator to the discount confirmation. Let's call it discount text. Do we tap page get by text and the discount confirmation. So let's copy it from some other test file. So we know that for example, here it says discount and then discount.

00:56 So over here, so we entered 2025 and confirming it here. Now we can add a quick assertion that actually this discount text is visible. And now let's remove the discount. First, grab the button, this X button.

01:16 So we have this remove discount button variable. Page, also get the button by role button, but different accessible name, of course, because now this button is remove discount. If you take a look at our form implementation,

01:31 that remove button actually doesn't have any accessible text content. So instead I'm using area label and labeling this button based on what it does. Here, remove discount. So once we have this button, let's click on it as well to remove the discount.

01:48 And now we need to write an assertion that this discount is removed. This is where it usually gets tricky. You see, if we just say that we expect our discount text not to be in the document, this assertion will fail. Because when we remove the discount,

02:05 it takes half a second for it to actually be gone from the UI. And that makes sense. We're recreating the server, actually taking time to process this action. But our tests shouldn't fail because of that. Our component still handles the removal of discount codes correctly. So here's where I normally recommend to apply a pattern of inverse assertion,

02:24 where you do something like this, like discount text removed, and you create a promise, where you actually create an assertion that this discount text is visible, so it gets retried in wait for, and then we're creating an expectation that is reversed,

02:42 so that this promise gets rejected. This is what I normally recommend, but with Vitest, we don't have to do this anymore. So instead, we can write a simple assertion. As usual, we expect element, so our discount text element, not to be in the document.

03:01 And the key difference here is this await, this promise. Because expect element has the retriability built in, Vitest will keep retrying this assertion until it succeeds. And of course, if it reaches the timeout, it will still fail. But this will give our test the ability to retry the assertion, and once this element is actually gone,

03:21 once our request handler awaits 500 milliseconds, and the element is removed, then the test will pass. So this automatic retriability is extremely handy, and you should definitely use it. There's one more thing to mention, though. Notice that for this assertion that the element must be gone,

03:37 I'm using to be in the document and not to be visible. Basically, not this. There's actually a reason for that. To be in the document only checks that the element is present in the DOM. Remember previously in this workshop, we uncovered that to be visible assertion, this matcher, actually has multiple assertions built in,

03:55 like for proper CSS being applied to the element, so it's accessible. But we don't care about any of that, because when the element is gone, all we want is to make sure that it's not in the DOM. Of course, it's implied that it's not going to have any CSS either. So this is a more suitable matcher to use when you test an element's disappearance.