Hey everybody! This is the Drunken UX Podcast. You’re listening to episode number 90 or we’re gonna be talking about running tests with Cypress.io with the infamous Jessica sacks. I am your host, Michael Fienen.

Uh warm, warmer. It’s humid now. It’s been raining for a week straight and if you’ve never been to Kansas in late spring when it gets rainy and warm, it is a bad place. Not nice.

Oh,

Uh let’s see if you are enjoying the drunken UX podcast. I want to make sure that you know to go check out designing for good, designing for good is a grant program that is running through july 26th. If my memory is correct on that, they’re gonna be giving away 3 $10,000 grants for a designer or developer market or to work with a local non profit. If you want to check that out, go to drunkenux.com/designgrants.

It’s drunkenux.com/designgrants. And you can get all the information on how to submit your 92nd video to maybe help out non profit.

I am easily swayed by the alcohol in my life because I am poorly maintained in my, I don’t know, Aaron, what are you drinking? I have a,

I thought you just, you left the pulp in.

That’s not gross. That’s the best part

I’m going wacky. This week I am drinking a mojito. Um, I, my, my wife got me a special bottle of mojito syrup at this uh local business downtown and I’ve been wanting to try it. So um have a giant bottle of rum. I built myself a little mixed station next to me. So if you hear clinking, I apologize because you got to make them uh not the cocktail world is not my normal dive, but that’s where I’m gonna be this week.

And I know Jessica’s joining us over there in boston and I discovered that she apparently lives with a mixologist basically and gets all the fancy treatment.

there’s not, there’s no duck in the market, there’s no there’s no

a little crispy duck skin on the rim, you know, just kind of hanging, he would do it,

shit folks. The voice you are hearing is that of Jessica’s sacks. She is uh currently the architect of component test frameworks over at Cypress. She started out as a manual QA engineer over in IOS. Um she went on then to do uh to be a software engineer at intent. She’s also the view test details, core maintainer and a view mastery instructor. Can you say? Show

Uh, let’s see. I want to start on this with a really bland question, but I’m just curious like, how how do you come from like QA engineering? I mean, I shouldn’t say that’s a stupid question. How do you go from QA testing? That’s literally like stones adjacent to each other. But how did you land at Cypress? What was like that journey to become somebody who’s like passionate about writing test frameworks and, and getting into this.

very cool. So as we talk about this, so Cypress is a testing framework. This is something you can go check out Cypress dot io. Um And they have built a suite of tools that allows you to make sure your code does what it should do. But that is a really bland way of putting it. Because you’re going to hear if you start thinking about testing or we’re looking into testing the stuff that you’re building, you’re going to find that there’s a lot of words that get thrown around.

Um And particularly when it comes to testing, you’re gonna hear things like unit tests or component tests or functional tests, integration tests. Just when people are talking about these things, what’s your sort of go to definition for explaining the difference between all of these things conceptually.

Yeah. And there are tools for all of these things. Um, and so like if we’re thinking, let’s talk unit testing, right? Unit testing, there’s a framework called Jest that that is pretty widely used that is designed to do exactly what you described. It goes in and you give it the function and it makes sure that I’m going to call this function with one and one and I should get back to.

And if I don’t get back to, then there something is not right with what’s happening here. and you feed it hundreds, maybe even thousands of these little guy tests. Um but unit testing in, in my mind is like one of those like it’s easy to miss the forest for the trees kind of thing. Like you can make sure every tree is there but making sure every tree together operates right gets you into like the integration level testing.

That was where I found Cypress probably two years ago, it was billed as this great integration test suite. Then we were using stuff at work like selenium for our into in tests and our functional testing and so and that’s all done in ruby, it’s all scripted out and it does all that you know render checking and land on the page, click the log in button, fill in log and go here, do this, do that and it checks that whole literally end to end.

When I found Cypress, it was integration testing now. I feel like especially after I’ve used it a little bit more, I feel very much like it can really do all of these things when I discovered that it can take screenshots and videos of the things that’s running like my world just kind of opened up the sun. Rose birds flew across the sky. It was literally the Lion King for me.

It’s funny that you mentioned the cookie thing because that actually factored into one of the test suites that I wrote with Cypress was we had some functionality that was enabled or disabled by a cookie that was set. So I went in and I for I was looking at it, I’m like well I can just pull the cookie like it’s javascript, I can have that cookie and know what it says.

So let’s uh let’s talk about the why behind this, the philosophical piece because I can already hear folks and I have been that folk because I work in a, you know, for a public company where, you know, you’re given X amount of time to do something. And one of the big challenges of course, always is, well, I have to do the work and now you’re telling me I have to do work to check the work.

So you’re doubling the amount of effort to put into this. So yeah, like why, why should I run tests if I can just look at it and no, it’s good. I’ll let just provide

I just want to interject and say, I love writing

having test coverage.

I,

the, you know, the thing I think about with this is when, when you are skipping the testing early on and thinking that you are saving time, you really aren’t, you’re robbing Peter to pay paul is the phrase like throwing out there because or the other one we use at work a lot is slow down the speed up because while I can write a piece of code and look at it on my screen and say oh, yep, that worked.

That’s because I looked at it in one single state, I didn’t test what would happen if I passed numbers to that function or passed an object to that function. I didn’t check what would happen if I passed something to it. That was out of bounds or anything like that. And one of the important parts of testing is writing the negative cases.

So what you end up with is yes, I could have looked at it and said yes, it did exactly what I needed it to do when I used it the way it was meant to be used. But when you start thinking about the fact that no, I really should be testing 789 10 different cases for something that includes all of these ways that could break it or should break it over time.

Trying to do that manually every time you touch that and fix the typo or, or at a comment, you save yourself huge amounts of time over the lifespan of that code by letting the testing automate that and just let it run and tell you it’s okay. And at least then you’ve got some of that coverage and it’s not protecting you from unknown unknowns, which is like the stuff you don’t know, you don’t know. But it gets you close to that.

At least you’re protecting yourself from the known unknowns at that point.

And I didn’t know that it was over

have known about that had it

the the sort of corollary piece of that is called B. D. D, which is behavior driven development. Um I there is technically, what is the acceptance testing driven development also, I don’t know anywhere that does that, I’ll stop my head, but I define B. D. D very differently.

Um I I have a huge code base that spans the years before I even got there and there wasn’t a lot of tests because there wasn’t even a build process or anything in place when I came in versus was before build process were even hardly a thing. Uh but I define BDD a little different. My BDD is bug driven development and so the way this is a real thing, this is, this is actually a strategy I’m using.

I mean, exactly, because we have so much code that doesn’t have tests built for it. The way I am sort of back door engineering testing into our development methodology is when those bugs come in, we write the test specifically for that bug.

And so it’s kind of test driven development, it is that sort of, let’s do the red green, we’re gonna write that breaking test, but we’re using the occurrence of bugs, is that opportunity to say, okay, let’s, we have to stop, we have to address this bug and define it so that we make sure we don’t bring it back.

It could be an actual pr problem for you in that case too because God, yes, if people lose faith in the tool that is supposed to do the thing that is good at.

I mean it’s kind of that’s kind of clever actually because it gives you a paper trail as to why is this thing here? Well now we know that can be really useful.

The thing that really helps you do is close your QA gap a little bit and a lot of our listeners, you guys are working at places that don’t have a dedicated QA. Engineer or QA testers or things like that. And so finding a way it will not replace it does not replace QA definitely doesn’t replace manual QA but it can at least shorten the distance you have to go in those moments.

Especially if you can convince yourself that all of that stuff you can automate through those tests is working well. It can really increase your confidence level in the other interactions and into and stuff that you want to go in and manually check out. So if that is something you have to do because you don’t have Q. A. This is where again that time efficiency stuff starts playing in that.

Yeah I have to spend extra time writing these tests. But you are saving way you know exponentially more than that on the tail end every time. Now you don’t have to spend that time on your own remembering. Did I test all the things that I test this that I do it this way that takes care. It’s it’s all it’s kind of documentation to an extent that way to

So I made a promise to focus at the start of this episode. This is gonna be about how do you how do you run tests to Cypress? So let’s start thinking about that. I’m going to use a super basic example since we can’t convey code over audio we’ll do this real simple but we’ll talk framework wise.

I’m going to leave it to you, Aaron set up the twitch channel where we’ll do the live coding examples for people that’s on you. You get to find the time in your calendar for that would be

It would be very fun. But I carving out time for it right now. First let’s start with what what do I need to know? I’m a developer. I’m a friend and Deb I I agree. I want to try to make some tests for my website. I need to know javascript. I would presume that feels like a safe bet in this case.

do a little bit. Yeah you need to spend some time obviously learning the commands of Cypress and by the way as I say this stuff they’re gonna be a million links in the show notes to help you out. So if you want to know all the commands there is gonna be a link that will take you to all the commands and the documentation. But commands are just javascript functions. Like there’s nothing special about them.

It’s no different than if you pick up j query right? Like these are just the things that you have created to accomplish whatever it says it’s trying to accomplish. Uh It’s a vocabulary. Think of it like a vocabulary that you have to spend time with and you need to know what those are. It’s same with if you were just learning vanilla javascript.

I think commands are easy. I think the one that might catch people a little off hand is that this word assertion? Yeah. Because an assertion doesn’t necessarily have a corollary in like vanilla Js or something like that. What exactly is an assertion library in the context of a test suite?

and and they help out with what you were describing earlier, right? This idea of making your tests feel like human readable descriptions, chai is really good about that and that you would say like okay yeah if I need this thing to equal one, I’m literally going to say I expect this two, you know to equal or equal or Should have length GTE. So you’re saying the length of this thing should be greater than or equal to four

So when when you look at like a Cypress test, you’re gonna see like a hierarchy, right? You see these what it starts with describe. And I think of that like as a category, almost like this is going to describe my navigation test. And so I’m gonna say describes navigational components and then I’m going to say it uh should have a number of nab items in it. So that’s that that that is the thing.

Specifically we are testing now we’ve used a couple of words and this is one area where I actually have remained slightly confused with with Cypress. Sometimes you say something should happen should is like a keyword, it’s an action or it is a command word, but then there’s also the expect function and I don’t necessarily know when to interchange these, but they are similar right there, both at their core saying at the end of this statement, something has to be true or false.

So when we think about how we get into this first test, first and foremost, we assume you have a directory, right? We assume that you’ve got a folder that you’re working out of. Maybe it’s a Git. Repo something like that one. The base requirement number one. Right. I assume you need to probably have NPM That’s a fair assumption. Probably. Uh and I think, let me see if I can do this off the top of my head. It’s NPM install dash G Is it just Cypress or is it at Cypress? No, it’s

that will install everything into literally just the cypress directory. Here’s the thing I want to make sure I mentioned on this because it’s incredibly useful and it will change the way you approach this whole product.

Make sure you go into the integration folder And in there there’s an examples folder and that examples folder has like 25 files in it that have literal examples of all of the different kinds of testing you can do from really simple stuff to really complex stuff and it is an incredible way to learn. I’m a big like, learn by doing kind of guy and knowing like, hey, I need, I want to try this kind of thing and be like, oh, I can just go see how they did it.

Yeah. Take a look at that code, tweak some stuff, changing things around, change some different stuff together. But I can see in practice how a lot of those things work. That folder is invaluable, so make sure if you’re starting out in this, that you take some time and you know, learn what’s in there, at the very least that, you know, there’s also a git repo of example recipes that goes way, way farther than that.

Yeah. And even like, it includes like, specific stuff, like, here’s how, you know, here’s how it would work on a blog. Um Here’s how some of the like API stuff works. We used it to test out an entire rest api framework we wrote

That’s where I was like hey I can do all kinds of stuff with this. Remember this? Yeah.

Uh you know, you learn things like, well I don’t need to run it like an open mode because obviously I don’t need the browser window to see everything at that point that you learn some of those little like quality of life adjustments that uh from there once you’ve installed it, the next thing you just need to do is decide what, you know what I’m going to test. So we’re gonna make something up for this case, right?

We’re gonna say we’ve got a site and that site, it will just assume it’s a WordPress site and WordPress generates navigation dynamically. And so we want to be sure that never breaks. So we want to see him in you And make sure it has, let’s say four items in it. We’re gonna have like an about a home, a contact and a shop button, something like that. And we know our site, we know that never changes.

So we’re comfortable just saying Should have four items in it to start writing a test. The first thing right you want to look for is that integrations folder. And this is where I when we were talking earlier about what kind of Sweet is Cypress? Right? That that folder integration gives you sort of a look into that past life as what it was kind of branded as. Uh but that’s where all of your tests right now.

Can you group things in there? Could you add like sub folders and stuff like that? Yeah. I

You may just order them by ticket number. Yeah

Do those files have to contain the word spec in them? I see that a lot in the repose or whatever. It will just pick up whatever.

we go into this integration folder, we’re gonna make a file called, let’s just call it navigation dot speak dot Js just for the sake of argument. And that’s gonna be the file that goes out and looks at our navigation that I know and I’m not gonna get into the specific code syntax, there’s a little bit of stuff. You have to throw it at the top of the file and you have to start with your initial describe of everything.

I’m trying to look, I’m trying to visualize files in my head, I have one right in front of me. Here we go, context. You set a context first. So you say our context is navigation and in this case we’re going to say something like before, which is before, it’s just a function that Cypress has.

There’s also before each, if you want to do something fresh each time a test runs were going to say before any test runs to a sigh, which uh, sigh is like the name space of uh the script just like you would use dollar sign for J. Query or another. Libraries name in an object name in its place. Side dot visit. Visit is a command. One of those commands we talked about and we’ll pass it local host. We’re gonna just test this locally.

So we’ve now told this script to go visit our local deV environment from there. Next. We do we want to do a describe next or do we start with it next or does it matter?

Yeah

But then you’ve tested it and now anytime you rerun your theme or whatever it is, you’re building any time that comes back wrong. Oh no why did I not have any nav items then you go in and you see oh well there was a I had a typo in and uh have menu items or something like that. Very very very simple kind of methodology but okay we set up this super simple test. How do I go about running that then?

Is it something that is something that I should just because I I you know, I I happen to know from using it. I can just open it and literally let it run while I’m working. And it’s constantly re running tests anytime I save files. But is it better to do it that way? Should I just run it on demand? Is what are the ways that you recommend? People run tests like this?

Let’s uh let’s kind of end on sort of a grab bag, potpourri of Cypress stuff, because here’s the thing, right, this is a huge tool that does a lot of things and a lot of things really well that we haven’t even touched on, we didn’t talk about fixtures at all, um fixtures just give you a way to step out information, like, you need to fill out forms, use a fixture to like, have that form data be the same every time or not, you can be different.

And so what we did, we’ve got a fixture that runs on forms and has an email address in there.

And I created a custom command in Cypress that will generate a random string and appended. It will, it splits the email address at the at symbol shoves that random string in there so that each, because we have a at the end to end side of this when this ends up in other systems, if it was the same email every time our records would get flatten and we don’t want that in these tests, we want to see new records.

So I use that method of a fixture combined with a custom command to make sure all of this stuff flows nice and seamlessly again, just javascript, javascript, just register your stuff and you’re good to go.

Can we talk on plug in for just a second because any good tool supports some kind of plug in framework that’s not new or anything. But I want to just call out something on this because Aaron and I have spent a lot of energy over the last four years talking about accessibility. Yeah, Cypress has the Cypress dash Acts library.

which lets you Yeah, it brings in the axe engine that you can then invoke on your page and it will run Acts as accessibility test suite and return again. This is only for the, you know, the stuff acts as capable of automating, which is What 40%, of issues. But still it allows you to with like two commands. It’s not even hard, it’s it’s like you invoke it and then you what does it invoke, invoke? Acts and check accessibility.

Uh so you run those two commands and if it comes back good, it comes back Good. That’s if you are looking for like a baseline way to get into accessibility and to make sure the stuff you’re doing is right. That is such a dirt simple way of doing it.

And I’m just like I was when I found that tool it was like remember when I said earlier the sun rose and the birds went and uh well the seas turned to wine for me and I had fruitful bounties upon my shoreline because it brought the whole thing full circle for me. Sorry, I’m getting weird. No, no,

we can’t go too far here because the one thing we didn’t really get deep into but I want to talk about is the component tester because this is a big deal for you guys. So What was it two months ago you guys released 70, is that about right?

How does Cypress define a component? Like are you specifically saying web component or are you using it abstract? Lee is like just a unit of code?

What of the things we haven’t talked about yet, if there was like one sort of golden nugget in Cypress that like that you see people maybe consistently discover and get excited about or something it does that like maybe just isn’t like off the shelf obvious, but it’s once you get into it it’s like, oh my God, this is opening the book for me.

What what would be that thing You would drive people to say go make sure before you discount Cypress, make sure you go look at this thing because it’s going to change your world.

or if uh it’s not your backing but somebody else’s if you’ve been a great because when you were talking earlier about like the need to retry tests and all of that you know you have some control over that if it’s your stuff but if you are integrated with the flicker api or the google maps api or something like that you don’t have control over if there is a delay in that response sometimes.

Awesome. Well while you guys go out and download and install your first Cypress package and start writing your test. We’re gonna take a quick break. We’ll be right back.

Yeah Jessica. Thank you so much for spending your night with us. I know that asking people to log in a little bit later from the East Coast is a little arduous but hopefully we didn’t make it too bad for you to compensate you completely and thoroughly take that microphone for a couple minutes, tell people where they can find you what you got going on and anything else you want them to know.

Uh, well, yeah, you send it to us, we’ll throw in the show notes and folks will be able to find it. No problem.

I will plus one you on the Discord Channel. Um, I joined it a while back, I have found that even though I haven’t been talking in it, just like seeing the stuff people are doing and talking about that in and of itself is really helpful from an educational standpoint. Like I’ve really enjoyed just sitting there and just kind of observing just it’s watching, just sitting back in the bushes, my binoculars.

sitting somewhere quietly listening, Michael, I am an introverted extroverted. Okay, that’s a thing. That’s the thing that I made up.

it’s if you are enjoying everything you’re hearing and you want to be an introverted extrovert, be sure to find us over on twitter or facebook at slash drunken ux or instagram dot com slash drunken ux podcast. If you want to chat with us on discord, we have conversations going on about all the things.

Occasionally when somebody asks, you can find us at drunken ux dot com slash discord as we’re talking here, I’m sitting here watching my ring pop up in my browser and saying, Hey, you’ve got motion in your backyard because of my dog keeps going in and out and in and out in and out and I have not told it yet to ignore things of that tiny size. I can’t write a test for that, but I can write tests for lots of things.

And I, I, I was really excited to do this episode because I got really excited about Cypress a couple years ago when we started using it. I’m thrilled that I’ve been learning it more and more. I cannot recommend enough that folks go spend a little time with it and what I’m going to commit to is it, I mean I shouldn’t say commit. It’s already done. It’s just not very far along with the redesign.

We’re doing the drunken You excite, I have Cypress installed in that repo that report is public. If you want to see any of the tests that we write for our theme development, you’re welcome to go in there and take a look at that. If you want to try writing a test, you’re welcome to use that as an opportunity. Right. A test against our site. I’m making that an open invitation. I’m not asking for help.

I’m just saying if you want to write a test and see how it works against the site, I am, I will allow you to test my site. Um, so please take time to do that. Because the one thing that’s really cool about testing is that when you do it enough and when you really commit to it at the time that it saves you, it really allows you to keep your persona is close but your users closer. Bye bye.