Debug and Log with Cypress
The Cypress programming model is similar to async and await. When you write Cypress commands, they will be enqueued to be run at a later time, but they will run in the same order as you write them.
Recommended Homework:
- Verify that Cypress commands run in the order you write them, and not based on when they asynchronously finish. Recommended solutions include using timeouts, and/or synchronously available values as with cy.wrap
Instructor: [0:01] In this lesson, we're going to talk about debugging and locking, which are critical in any testing environment. We're going to use this as a way to take a look at Cypress' asynchronous nature. Let's start off by trying to add a debugger as we normally would.
[0:15] If we visit Cyprus and pop open our console so that we make sure we hit our debugger, we'll see that the page actually hasn't loaded yet. This is strange because the debugger is the third statement.
[0:29] The first statement is that we visit the page. The second is that we get the first to-do item. Then we should be hitting the debugger.
[0:36] What's going on? If we press play, now we finally see Cypress load the page. We see it visit, get the first to-do item. This gives us a hint as to what's really happening with Cypress.
[0:49] Cypress code is a lot like async and await. When we hit the cy.visit method, we don't actually visit the page yet. Instead, Cypress on-queues the event to happen later.
[1:00] Think of this like pushing visit into an array and then moving on immediately to cy.get. Cy.get is also asynchronous. It pushes that into the array, followed by the should, then the should, then the find, then the should. These will all be executed in order, but they won't be executed yet.
[1:19] Next we move on to the debugger statement. This is the first synchronous line of code that actually runs. That's why when we hit the break point in our console, we haven't visited the page.
[1:28] We haven't run a get, a should, or any of the other Cypress code. We hit that debugger. Nothing is loaded.
[1:35] Next we hit this cy.get. We proceed on-queuing events in the same way as before.
[1:41] Finally, we start popping things off the queue. We visit the page first. Then we run cy.get.
[1:50] If we want to see what cy.get has actually gotten, we have to put our debugger in here. Then takes a callback, so we can say that this will be the element. If we put our debugger statement in here and save it out, now we can reopen Cypress and see what happens.
[2:13] We hit our first debugger from before. We see the page isn't loaded yet. That's exactly what we expect. Let's press play and see what we get. We hit the second debugger statement and were fed the element.
[2:30] We can access the element, which we see as the jQuery selector. We can interact with it as we normally would.
[2:37] Of course, this is a little tedious. Cypress provides a helper method called .debug. If we run .debug, it'll be the same thing as putting a debugger in, except now we'll be fed the subject by the name of subject, which we can inspect here, or as a named variable.
[3:00] Similarly, if we want to log something out, we can use cy.log and say something like, "About to fetch the element." Now if we reload the page, we'll see cy.log in our list of statements.
[3:18] Arbitrary code can be on-queued into Cypress using cy.wrap. For instance, we can wrap the number five and say it should equal five. If we reload, we'll see this assertion ran, and it ran in the same order we expected it to.