Write Your First Cypress Integration Test

Instructor: [0:00] In this lesson, we're going to write our very first Cypress test. As usual, let's check out the branch associated with the lesson.

[0:09] Up until now, we've been looking at the examples that were generated automatically when we first ran Cypress. Let's go ahead and blow this away and create our very first integration test. We can call it to-dos.spec.js.

[0:24] We can see in our Cypress runner that to-dos.spec is created here. If we click on it, it will find no task in the file. Let's go ahead and write one.

[0:34] We'll start with a describe block and describe our to-do application. Inside that, we can create an it statement. We can say it loads the page. Now we'll just visit it. Let's cy.visit at the root of our application. When we visit the page, we'll see that Cypress loads our to-do app.

[0:54] Describe an it are provided by the Mocha testing framework, which you can tell if you hover over them with your IntelliSense. Cypress itself is build upon a lot of existing best practice libraries like Mocha and jQuery. You will be familiar with some of the nuts and bolts.

[1:10] Let's learn how to use our cy commands. We've already seen how to use cy.visit. The next thing we'll learn is cy.get. Let's get the first item in our to-do list. Cy.get, we pass in the selector to-do list which wraps all of our to-dos.

[1:28] We implemented to-do items as list items, and we can use nth-child one to select the first one. For assertions, Cypress includes the child library. If you're familiar, you can use shouldHave.text Hello World.

[1:45] If we head back into Cypress, we can see that task already ran and that it passed. We can step through each moment and time.

[1:52] For instance, when we first visited the page, after we received our XHR request to the backend to load all our to-dos, when we targeted this first list item, and we can see what was targeted here on the screen, and then we can see our assertion which targeted this list item and expected it to have the text Hello World.

[2:11] If we want more contextual information, we can pop open our console and see a little bit more. We can see, for instance, the command was asserted. We expected the text Hello World. That's what we got. We can see our subject, which was this jQuery selector of the list item.

[2:28] We should also probably check that the testing just passed because of a fluke. Let's go ahead and change this to Hello Mars and reopen Cypress. We'll see here that the assertion hangs a lot longer this time. The reason it does that is because it's waiting for the text Hello World to change into Hello Mars.

[2:45] This is part of what makes Cypress so reliable. You don't have to write any code, sleeps or waits until an appropriate moment when the repan has happened. Cypress handles all of that for you.

[2:57] Let's go ahead and undo that. We'll keep chaining some more should off of this to see how that works. Let's say it should not have the CSS class completed because we haven't yet completed our to-do. Back in Cypress, we see the chaining like this works. Both assertions ran one after the other, and both passed.

[3:18] Cypress also bundles jQuery. We can use the jQuery method find or similar methods to navigate our UI. For instance, we can find the toggle, which is a child of this list item, and then we can say that it should not be checked.

[3:35] Back in Cypress, we can see the way this gets targeted. For instance, first, targeting this first list item, and then we can see it targeting the toggle, and asserting not checked on that. It's important that we run this check on the toggle because a toggle has a check or not check attribute, but the list item does not.

[3:55] To see this example in action, let's switch to the second list item which has the text, Goodnight Moon. We know that this does have the class completed because we already completed the to-do.

[4:08] What happens if we still say it should not be checked. Reopen Cypress. We expect the toggle not to be checked, and we see this fails. However, if we run this same assertion on the list item and not the toggle, the test will pass.

[4:24] The reason is because the list item doesn't have a checked attribute in the first place, so of course, it's not checked. This is why it's important to double check that the inverse assertion of any assertion you make does in fact fail.

[4:37] Since we know the inverse fails in this case, we can retarget the toggle and make sure that B checked passes. Since it does, we know we've targeted the right element.