Testing Web Apps with Cypress

Checking the Current Path

Steve Kinney

Steve Kinney

Testing Web Apps with Cypress

Check out a free preview of the full Testing Web Apps with Cypress course

The "Checking the Current Path" Lesson is part of the full, Testing Web Apps with Cypress course featured in this preview video. Here's what you'd learn in this lesson:

Steve explains why checking a page's URL can be more reliable than querying content in the DOM. The location method can query the current path and compare it to an expected string value. The title method, which queries the page title, is also demonstrated in this segment.


Transcript from the "Checking the Current Path" Lesson

>> Let's talk a little bit about some of the other parts that are not necessarily on the DOM. One of things I think I alluded to earlier, I think I said it while we were recording, might have been during a break, but if not so I'll repeat it.

Is that there are other parts of the page in the browser that aren't necessarily in the DOM. So like querying for them is not always going to be the be all and end all. Luckily, we have a bunch of different abilities to get other information from the browser.

Namely, we do have access to the window object. We do have access to the document object itself, right? And like document.title is whatever the name of the tab or the window title is, the title attribute, right? That's not in the body. But it is a thing that we can kinda get ourselves.

If we wanna figure out whether or not navigator has that online or not, checking like the battery status API whatever. If you needed to check those things or set them or as we'll see later, mock or stub them to be different values, you do have access to all of those things for the purposes of writing your tests.

We're gonna stick it out with some of the more common ones that you might use, right? So I have the situation where as they navigate through the app it's a client side app, I want to make sure that the title of the page is meaningful. It shouldn't just say 10 portal at the top.

It should say 10 portals and maybe it's your workflow executions or your event history or whatever page and that should change as you navigate around this single page application. Also doing certain actions, right? We have it, so we have a bunch of filters like you saw in the previous secret item menu thing, right?

I have it set so that if you change any of the query for sorting and filtering your workflow executions, you change them on the filter, it changes the query pram. If you visit that page, it sets the filters automatically. That way if you'd like hey, I only want workflow executions from the last seven days, sorted by search and search, right?

And you want to share that as a bookmark it as if you go back to or share with one of your co workers or something along those lines it's serialized in the URL. So I need to be able to test that these things work. Because even managing the query params as you navigate around is actually a little bit trickier than one might want it to be.

So we have access to site title, which is document.title. There is site a document, site out window, right? All of the use cases would be very contrived, but like if you do need access to something on there, you can absolutely get it. But we'll look a little bit at site.title and site.location.

Location does require an argument which is basically an alias to window.location. But it's like which one of those properties do you want? So you say site.location you can get like. In a lot of cases I almost always want either the path name or the search params which are similar to query params in this case.

But if you did want something else along the way, you can get that and two string are effectively the full URL, right? So you can be like hey, it should include this piece in it. So if we're on this page, it should include this, right? Or the query params should have this key equal sign, this value.

If I've manipulated the page in such a way, right? You test all those things to make sure that they, there's other things that are quietly break, right? And then all of a sudden your app is not behaving as you expected. So let's go take a look at that.

We'll go into yet another application. This one's got a bunch of things. Let's take a quick second to just admire it. So this page, it does have the ability to sign in and sign out. And we have the different pages so on and so forth, where we might want to see are we on the right path.

There will be cases where if they go to slash posts and they are not logged in they will get redirected back to the sign in page, right? So functionality like that is not always a thing that you maybe, you'd be like, okay, they should see the sign in button.

And that is correlated with them being on the sign in page. But not really right versus no there on the URL for signing in is a much better test in this case. So how would we go about doing that? So let's take a look. So we'll go over seven and I will do a few of them and then you can take a look as well.

The other part that we're going to look at is form validation, right? Either you're using the native DOM validation logic. If you put a require they can't submit the form without it or you have some bespoke maybe your server side rendering apparatus is doing it. Something along those lines to make sure there's different customizations in there.

I'm going to just for the sake of this workshop, I'm gonna assume that we're gonna use regular built in DOM form validation. But the same principles apply if you were doing it by hand as well. So what we want to see is that when we go to echo chamber that it shouldn't just be like cybers workshop.

It should be like echo chamber and then like that's part of this like, cybers workout. This is a social media app where you can only talk to yourself, just FYI. It's a database, you just yell into the void. You can make multiple accounts and get into fights with yourself.

But there's nobody else listening. And so as opposed to just either, admit some stuff to yourself that maybe something you got to think about or just really just rant. You can have it, you can use this application as much as you want. You have my blessing. So let's go make sure that the title is what we think it is.

This is simply as simple as doing site title which is going to in that chain give us back the title, right? So in this point we're gonna say that it should, I just care that it should contain echo chamber. Now there might be a world where it's like hey, they're on it's like account colon in the username, right?

You could use a regex in here and you would use match instead of contain, right? And you would pass it a regex, I think depends on what you want to do as you let autocomplete be your friend. So you just type this, just start typing whatever you think it is.

And you'll probably find what you were looking for at some point. So we've got them there as well. We're gonna go with contains in this case. So make sure that that passes, so we'll need to go back to Cypress. I'll stop it. Let's go back to echo chamber in this case, let us start up.

All right, so it should have the title the application there. So go visit echo chamber. Expected echo chamber/Cypress, front and masters to include echo chamber and that it does. Other thing that we're going to deal with a little bit as well is you can also see that this made an API call at some point, right?

So you'll be able to see all those without looking at your network tab as well. And we'll talk about how to either intercept those, mock them out or just watch them and spy on them and stuff along those lines. And as we go through as well. The other thing we wanted to do was when they click on sign in, it should take them to the sign in page.

And you can guess who's gonna do the other one? I'm not, I won't ruin it. I won't ruin the surprise for you, but I'll do the first one real quick. And so they're going to navigate to just the core page. As they do that, let's see what happens.

Just click on that, okay? You end up just the raw HTML the raw page where you're asked to go sign in sign up. So you could write a test that says like does this have this page on it, right? That they weren't redirected does it say the right thing so on so forth.

We're not going to do that right now. We're just going to say, let's go take a look at what this button is called. That's cool, it's called data test sign in. That's a good name. So we'll go in there. And we'll say, go ahead and click on that link.

And then we say hey, Cypress, we're gonna say go get the location. And nice that autocomplete is your friend here, will say that the path name now you got some choices. You can go with exactly to equal that, right? How's that? Should equal no What I would probably do for this one is like it should just end with, it should contain.

Or I think there's an ends with. Let's try that one a second echo chamber/ sign in. So that was the test that we had in this case, what it says to only just verify. So you can see I'm on that page. That's what the URL is. I believe I can do.

So thought there was an worth, maybe not. But you could theoretically also make sure that just has yeah. If you don't necessarily, cuz equal not work like the query parameter, right? So if you have a query parameter something along those lines, not gonna equal that anymore. At which point you just want to make sure that it has the part of the URL that you want.

It all depends on your use case. So you can like make the best decision for you

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now