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

The "Aliases Solution" 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 live codes one possible solution to the Aliases exercise.


Transcript from the "Aliases Solution" Lesson

>> So we wanna take some of the tedium from finding some of the selectors like because, again, like there's not that many things on this page, right? There's a list of packed items is also unpacked items, there's some inputs, there's some buttons. But I love to do, it's just to hold on to those and not have to go searching for them all the time, right?

So we use some aliases in order to do that. What I might try to do is to the filter and maybe we'll move one from one list to the other. So if I think I'm gonna use them throughout a set of tests, it probably behooves me to do that in the before each block.

Otherwise, I will have to do these in every test at which point I've kind of defeated the purpose of storing them in aliases, right? Like why wouldn't I just do them once, and then have a reference to them that I can get my hands on later? One caveat that I will just kind of put out now again, to put them into a bookmark in your head is runs before you do anything else.

Which means if you go looking for things that are not on the page yet, right? For instance, like the one you're gonna click the button add to the page, it's not gonna find anything, right? And so you're gonna put the rules of the sun, an alias rule is a rule of again, right?

If you go looking for something on the initial page, and it's not there yet, all your tests are gonna fail or whatever tests we're using we're gonna fail, because it's not on the page yet, right? So this only works for things that are there before each test. Otherwise, you can either have a nested describe, you can do a whole bunch of other things.

But if your plan was to like store one and then navigate to that page afterwards, it won't work. Because when you went to go looking for it you're not on the page that had it yet, right? So even if I put all these before I visited the page Itself, they will fail for a good reason, because they weren't there, because they didn't go to the page where they were.

Okay, so what if we wanted to get, we know we wanna have at least the filter component, and we wanna have maybe all the items, the packed items in the unpacked item? So let's start with the filter items, you can verify this by going into the playground. So we've got the filter items, we'll call it as you can choose, you wanna call it filter input, item filter, we'll call it filter input, right?

So we've got that, and now I need the three lists, and we saw in the previous tests before that they are items items unpacked and items packed. So we can go ahead, and we can try that out, and we'll say, all items, and yeah, these are strings you like camel case, you can use camel case, you like hyphenation you use kebab case as they call it.

I don't even know what I like honestly, it depends on the project, I think like kebab case more. But then I think about it in terms of JavaScript variables, it doesn't matter just don't get your teammates to hate you and just be consistent. So they're just strings, whatever you wanna call them will work.

In this case, I started writing camel case, so here we are, because you can argue that with HTML they have hyphens, I'm not arguing though with anyone right now. Items unpacked should be, we'll call that unpacked items, and then the packed ones are like the unpacked ones with two letters less.

So now, I have these as aliases that I'm setting before every test, which means I don't have to go looking for them. I just reference the ones that I need, and do the things that I need to do with them. So if I wanted to kind of do a version of the filtering that I saw before I could say something along the lines of it should be filter items.

It's not the best test name, but that's life going, so we've got that, it should filter items, it just should filter items. And so here we can say, okay, side I get in this case, we're just gonna say at filter input, type iPhone, and if they do that all the items, right?

So I could say, Go look at all the items on the page, all atoms should not contain the text hoodie, which does not have the letters iPhone in it, right? So let's go ahead I think I need to switch to the other testers points, we'll stop those, we'll go over the aliases.

All right, and that asserts that it is not there, and you can see on the page what is there, so you can visually confirm that the test is doing what you want. We could argue that another test like we wrote previously was to do the same thing, but verify that what we think is on there as well, but this is mostly getting us comfortable in this case with the aliases.

All right, let's live code one more here where I'm gonna get to the point where I find one, I click it, and then I hope that it is on the other side, right? So should do that, we wanna verify something along those lines, which means go find one, I don't even really care which one it is, click it, and then verify that is now in the other side, right?

So go ahead, and we'll say, I'm doing this one just it should move items From one list to the other, right? And so we'll say That, all right, from the unpacked items, so we'll say side I get I unpacked items, go get me the first one. And again, like in this case, could I do that in the before each, right?

But maybe added one to the screen this is again, you don't have to be in the before each, it's whenever you think you have it. If you wanna share it amongst all the tests it needs to end before each, if it's bespoke to one, then you just need a reference to it that works as well is like I don't even question.

I don't know, cool, and then now, I have a reference to this one, so I have it as the overall item, right? And I also can then go find this checkbox for instance, right? And so I can do something along those lines, I'm curious this is like how I would literally do it if I was writing the test which is do I like, yeah, I wrote the sample apps.

I don't even really remember did I do that trick where you put the label around the whole thing? So you click on one it moves, did I not do it? Do I need the checkbox? So what I'm gonna do in this case is go ahead, and just click on that one, and see if I get the effect that I want visually.

Again, this is how if I was literally writing a test at the portal, how I would probably start to like very iteratively put together the test. Because yeah, like I'm fine doing that, because then the idea is I've done this. And now it'll run automated from that point forward, so we'll go and find the item question And we'll go ahead and we'll click it, Right?

And so let's say, let's go ahead, and just rerun this test to see doesn't look like anything moved. Looks like, you're unclear what I maybe have to find the label in this case rather than the LI itself, so we could do something As well. Okay, this one I can only click on a single element, and I gave it four elements, right?

That's interesting, right? Because I thought this was the first one in there, cool. So not totally sure in this case, what's happening is clicking worked. One of the things I can do as I go through is yeah, I didn't question seems to be the entire list, right? Yeah.

>> Is it returning an array, because we don't have the LI?
>> It is probably, if this has the h3, this like if I go up here, I can kind of see that pin, it's now going to my console, right? It's the section, right? So yeah, it's working, right?

It's just not what I thought should be in that case, which is yeah, unpacked items, the first one is the section. There's only one thing it is the section I have a no hope in this case, right? But again, this is the interesting part of the debugging, which is you get every step along the way to see what it was as we went through.

So I can go up, I can pin it, which one will it log into my console and show me the element in this case. But also you notice as I kind of hovered over I can see what I got every moment. So I'm not just throwing code at the wall here, I am literally kind of just watching as it steps through everything.

And this is where the tool itself becomes incredibly powerful, because like there's a unit test. Let's be honest, what we'd be doing right now, console logging, right? But I don't have to do that, because I actually have a visual tool around us. All right, so what I might do in this case, really because we want to make this a little bit better is I probably want to go find an ally in this case, right?

Maybe I actually wanna find the label I'm not totally sure yet, what I wanna do. So we'll go ahead and we'll try it out, this point you can see that it moved, right? So now the actual exercising of this totally works, and we now just wanna verify that what ever we clicked on, in this case, it was the toothbrush moved over.

And again, like if you have to hard code in toothbrush I guess find for like as with dummy data when you're just learning. But ideally, something where you can refer to the thing and make sure whatever it is moved is probably better. So the item in question, right?

Is the first LI, so I could say, let's try this was a site I get we're gonna say, packed items, right? And then we're gonna see if we can find, do I wanna look for the text? I'm not totally sure, see this works actually. Like my sense is like, this is where we're moving from the page and putting back on it's maybe not the exact same item.

So yeah, the only works of the get, and so really we kind of just need the text in this case, right? I wanna make sure that something with that same label exists, because depending on the framework, it might totally rip that element off the page, and put a new element on rather than moving it, right?

This is felt in this case, by like we act reconciler is gonna do different things depending on the use case. You don't wanna like hard-code your implementation to the nuances of whatever reconciler compiler is doing. You wanna basically make sure that the thing is what you expect, right?

So I could also like have an alias for the label, right? That seems good, because then I could theoretically get its text, right? So I could, and this is probably a little like for one test like I was doing this for a lot more, so we could do what we had there, and we could say item label, right?

And then we could also again, depending on what I need for the test in this case, since I will be clicking on it in a second, I could go ahead and say, item label, and then I can invoke its text. And I can store that item name I don't like, the navy part when I'm making this up is probably a weak spot.

But now, we wanna say, go ahead, and we still need to click on it, right? So here, we'll do, and I'm pretty sure there's fun stuff you can do like remember, like you go down and up across the chain since I have these, I'm not doing that. So go ahead and get the item label, And click on it.

So really these first three, I'm making a bunch of values that I can reference. Go find me the first item, go ahead and find this label. One would argue I could probably make this one alias as well, maybe we'll try it in a second. Then go ahead and click on it, and then I wanna make sure that the packed items contains this item name.

And so what I might do here is get that as an actual value, right? And so this again, if you have two cypress things, and you wanna be like normally, if you're just writing this in a unitest, you'd be like expect variable to equal whatever, other variable. In this cases, there are chains how do you mix two chains?

So one of them I should probably get down in this case, I could say side I get an item name. And we could say then with the actual text go ahead look the packed items, do you have that text? Works, you see that it does, right? So let's just talk about this one more time, without a big intelligence thing in the way.

Again, since I'm not really using unpacked items anything, but finding the first one, I could probably go find the label as well or the first label, I'm guessing, I could probably just swap this out. Let's see. Find label and they got the first one. All right, so I took a step out of there, like go the unpacked items, go get any of the labels, right?

Grab the first one, I need to hold on to that, I also wanted to text, because I need to go click on it too. So give me the label, give me its text, click on the label, or the checkbox in this case, right? Cuz it's wrapping the checkbox.

And then when we actually have its value, go ahead and make sure that content is on the packed item, right? So you can kind of store stuff as you need it, and be able to kind of get those values as you go through, right? And like I said before, aliases are fine for some of these selectors, other things you could do here if you wanna do, there's a bunch of ways you could do this right?

Here we're trying to take stuff on the page, an alternative approach, right? If this is like stressing you out a little bit, you could have just had like a value that you added to the page by typing in the form, right? And then you can go find the element that contains that, click on it, and move it to the other one.

That you'd probably have one for the input, the button click the two forms. There are different ways that you can go about doing it, it's about the kind of flow that you have. In this case, we had stuff on the page, so we went and found it, and labeled it, so we could use it later, you might choose to add stuff onto the page.

There's a bunch of things that you could do in this case, you could just be like, listen somewhere at this point I could theoretically do the dot then here as well. And get rid of an alias to, right? So go get it text, See. I could refactor it as well.

So finally, I'm late we'll get this text with that text, go click on the item label, and make sure that the packed items contains it, that works as well, right? So there's different ways that you can do it, and like I said, I was kind of extemporaneously live coding this one.

So you could refactor it as well, but there's yeah, different approaches that you can take along the way.
>> Is it important to discard these aliases when they're not needed anymore?
>> I mean they'll get cleaned up by the describe block, they only live as long as either the test that they're in, or the describe block in this case.

So you by definition the same way we're revisiting the page, like we lose everything on every test run, right? That's why before we go to the page as a fresh page, right? Each time.

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