Hasty Treat - The Future of Testing with Cypress

CSM.

Welcome to Syntax. In this Monday, hasty treat. We're gonna be talking about The future of testing and Cypress.

Those of you who have been following me on Twitter might know that I have switched all of our UI testing entirely to be Cypress. So I thought it would be a neat time to talk a little bit about my thoughts on it. Not to mention, I also just did a course on it. So Cypress is very ripe in my mind right now. So my name is Scott Talinski. I'm a developer from Denver, Colorado. And with me as always is the West Baals. Hey. I'm excited to hear about all these updates to Cypress. We talked about it, A year and a half, 2 years ago on the testing show? Yeah. And it's it's come a long way since then. Yeah. I know. Cypress has really grown up and all of the features that everyone has asked before they keep on delivering it and so much more. So, I'm I'm really into it. I think it's a fantastic solution for anybody, especially those of you who are potentially a little bit put off by testing or afraid of testing. I know afraid of testing could be, like, listed as, like, one of those things, a skill on LinkedIn. It'd be like, I'm efficient at JavaScript, afraid of testing. Like, that's definitely a developer profile. That's great. Yeah.

Well, this episode is sponsored by 2 awesome sponsors, DQ, not Dairy Queen. We're talking DQ, d e q u e, And LogRocket.

LogRocket is the visual error and exception handling service that allows you to see how your errors and bugs happen in Real time by watching a scrubbable video replay.

This tool fits right at home within this series or within this Episode because this episode is all gonna be about visual testing and visually understanding how the site's being used, and that's what LogRocket's about too. It's about seeing how these errors happen in a visual window. So give it a try at logrocket.comforward/syntax.

It's 14 days for free. They're going to be very impressed because there's not another tool out there like this on the market. Let's talk about Deque Systems. That's d e q u e.

They are the experts in web accessibility, and they have really, really sweet developer tools that tells you when there is possible accessibility issues in your So I thought, how fun would it be to throw myself under the bus for this Saturday and see is there something wrong with my website that is a possible disability issue. So I ran it, and if I had a couple things, I'm gonna tell you about one of them.

One of them is that I didn't even realize this. This is actually something Scott Pointed out on a couple episodes ago is that I don't have a main to either a main tag or a role of main on one of my elements, and and that is required, so that you know where the the main content is on your actual website. And I'm not using either of those, so it's very hard to be able to skip to, like, the blog post or the the meat of what the website actually is. So that's just like I just ran it on my website. It popped up and says this is the issue, and then here's the element where the issue is on, and here is how you can fix it. Link off to some docs about why it's important and how to actually fix it. So awesome little tool. You can just, like, run that thing through the website you're working on, create a couple issues in whatever bug tracker, and these are things that you can usually fix pretty quickly.

If you've got, 10 minutes here or there, you can Quickly fix those issues. So do that for whatever website you're working on right now. Check it out at dque.comdeque Forward slash axe a x e. Thanks so much to DQ for sponsoring.

Alright. Cypress. Let's let's hear about it. So it's end to end. Maybe we should clarify what that is Really quickly,

what's your explanation of what end to end testing is, Scott? Yeah. So, primarily, you're gonna hear things like Starting at the most micro to the most macro, you'd hear something like unit testing, and that tests basically an individual function. Right? Your test is to make sure this function works. Then you have integration testing where you could think of integration testing as how do these 2 functions or these 3 functions work together? Like, how do these small systems work together, and are these small systems working? And then you have end to end testing, which means that the entire application is basically tested as Is in terms of, like, as the user will be using it in the entire application.

So in its real environment too. Right? Because, typically, when we're working with these unit or integration tests, maybe it's, like, even React code that you're testing, but it's running the test in Node in only running those couple of components. Where with, like, an integration test, you're gonna have your full site being, I mean, with end to end, it would be loaded up into a browser URL, and The test is being tested against a real browser and usage in that browser. So that's pretty much the big difference between those varieties. And so Cypress is an end to end testing solution as in what it's doing is it's loading your site from a URL, And you could even, like, point Cypress to, you know, west boss dot what is your boss dot a f? Whatever your website is, you could point it to the production website. Of the stickers? Yeah. Yeah. And Cypress just, like, isn't going to care. It, like, will not care if you point it to any website.

All that matters is that this thing is accessible by a browser, and Cypress will load it up. It literally does the the mouse moves and the clicks and the and the whatnot for you. So, like, you know how, like, A lot of people's testing method is just to click around and make sure it still works.

Cypress will do that, but you can automate that clicking around And making sure it still works. I'm doing air quotes here because you actually check for actual elements on the page and assume that the the values are what they're you're expecting. Right? Yeah. Yeah. And it uses jQuery under the hood to this very jQuery like selectors. So you do, like, c y get, And then you'd put your selector in there, whatever it may be, and then you say, c y dot it and dot should exist. Right? This thing should exist. This thing should have a length of 5. There should be you know, you you look for all of the cards on the page. There should be 5 cards, and that's really how you're writing your test. And, actually, what's neat about our setup in Cypress on LevelUp Tutorials is that we were really used to React testing library, DOM testing library way of doing things With data test IDs, and there's a plug in for Cypress that allows you to use cy.getbytestid,

which is like It's they call it Cypress testing library. It's basically in addition to Cypress to make it more like React testing library, DOM testing library. So I I really like that way of doing things. We should explain what a a test ID is as well. So if you wanna be able to grab on to an element, like, let's say, shopping cart, and you wanna make sure there's Six items in your shopping cart. Often, what you'll do is you'll put a data dash test ID on it, and it's very similar to just throwing a class on it So you can grab the thing really easily, but putting a class on it is kind of annoying because classes are used for for your styling as well. So Not to muddy up your classes, you just add data dash test ID to it, and then that's very clear that that attribute can be selected, and you can use data dash attributes both in CSS as well as in JavaScript. In this case, it's using JavaScript

to grab the thing. Yeah. So we primarily look for all of our things by those data test IDs. I I like that flow.

And one of the downsides to Cypress in the past this is gonna sound a lot like an ad for Cypress because I just like it a lot. Typically, the things I really like to talk about, I like to talk about. They'll they'll come on for a sponsor after this. Yeah. Right. Yeah. I I You know what? We've been using it for a long time and to some degree, it's like it basically went up from the minors to the majors right now because it was basically a a sideshow for us, and now it's, like, the main show for our UI testing.

And in the past, the problem with Cypress was it only did Chrome, And that wasn't necessarily great because, you know, many bugs you encounter are gonna be Firefox only or Safari only, maybe, more frequently, Safari only. But now it can do Safari. It can do Chrome.

It can do Edge. It can do Firefox, And I can do all of those. It's it's really nice and easy. And for me, that's a a big win. I probably mostly end up just testing in Chrome anyways, but The fact that it can run them in in any of those browsers is is really nice. And so one thing that we have yet to really talk about is that, like, it's a visual tool. So you write your tests, but when they run, they run with a real browser that's iframed into, like, a a checklist. And you can physically see the mouse move around and click, and you can see the checklist go down. And if you pop open the network or the network tab or you pop open any of the Developer tools, you're going to be able to use those developer tools like you normally would and at least be able to see the outputs of the logs and things like that, which makes it Quite a bit more friendly than, like, the black box of Jest. Like, we had so many issues with Jest failing for some sort of node reason or TypeScript reason Or just any sort of random weird situation. And it was so hard to debug because we just could not figure out what the heck just was expecting from us or whatever. It just was this giant black box. Where with this, if my tests are failing because the website isn't working, It's pretty easy for you to see that because it's happening right in front of you in an iframe, which to me is is really big. I'm a pretty visual person. So The fact that it it pops open and you could see it running in a browser, which is how we normally use our sites anyways as developers, to me, that just makes it feel way more at home. Right. Because you spend all your time in the the browser.

Test is failing because there's something that's happening not even outside of the browser. Like, Let's say there's a bug happening because of the way Node is interacting with your thing. Like, let's say you you fired up your site on a browser. Site works fine. The feature works fine. That's all good. Right? But then you fire up your test of dough, and all of a sudden, the thing doesn't work. Well, that doesn't really make you feel very confident about your testing solution Because that's not how the users are actually using your site. I mean, people are using your site in a browser.

So for me, that's why it's always made a little bit more sense. But you don't have to run a visual. You can run-in in a headless mode as well. We run it in our CICD via headless mode, and it just gives It's a little output like a normal testing utility too. There's also this, really neat experimental feature for React component testing.

I have not tried it yet. I don't know if we will use it, but I haven't tried it yet. One thing I'm wondering is how many people are using this to make bots?

Because It seems like a great way to, just script clicking and typing and and whatnot on a really nice API. I wonder if I bet it is. It's gotta be. You could do that pretty easily.

Actually, that brings us into, like, another point here. They recently in, like, the latest version of Cypress, Which just came out, like, a couple weeks ago. I was really lucky that it came out, like, while I was recording my course because it's a pretty cool feature, and this is automation So, like, write tests. It's called Cypress Studio, and it basically gives you a like a recording light.

And You have the browser that's in an Iframe. You click the record button, and then you type in an input. You click a button. You navigate the site, And then it literally writes the code for you to do all of that. So so you pop over to your test, and the code's already written for you Surrounded by a comment saying that this was automatically generated by Cypress Studio. So the idea would be that you would use the site to the, like, full extent. It would write all the tests for you, and then you would write your assertions in between that logic to click around. So it's telling you to click around. It has, like, an empty Form field, you type in that form field or whatever. That automation's gonna be all done for you. And then in between those lines, you can write, well, I expect

When I type this in, it should do this kind of thing. That is so cool. And I was just thinking about, like, how awesome that is that you can do that all in JavaScript because I was writing some shortcuts for better touch tool the other day, and they have similar thing, but they don't record what you're doing. You have to just put in 1 by 1 by 1, and I was like, how awesome would it be if it or recorded your clicks and mouse movements and then replayed those back on top?

And that's that's exactly what this thing is doing. Right? Yeah. Yeah. Totally. And it's it works very well. It's listed as an experimental feature still, But in my experiences with it, it was pretty flawless. I I didn't get into any, like, really rough stuff, but for the most part, it worked really, really well. What about, like, data? Like, if you're hitting an API in your thing, do you still actually use real data to go out to the network to get it, or do you mock that data? So us, personally, right now, because of how our API has changed, we temporarily have it Hitting all the real APIs.

So it's hitting our sandbox brain tree. So that way, when it tests, subscriptions, and stuff. It's testing on a real MongoDB.

It's testing with a real user account, And it's testing with the sandbox version of the API.

And granted, that's probably not something we're gonna wanna do forever in actual code life, but you can do it that way. There's nothing stopping you from doing it that way. In fact, you could point it, like I said, Said it won't care. It's gonna just use it like a robot. There's nothing more real world than that too, isn't there? Right. Seriously. It's it is it is the real world here. If if you had some VR glasses and you'd watch Cypress committing a test in VR, you'd be in it, man. You'd be in the in the cone. That's the real deal. Yeah.

But there's also, like, really complex mocking in, fixture support. And one of the new features again with this very recent feature is called intercept, Which basically man, the code for this is really pretty easy. But let's just say you have an API that's returning An object of in our tutorial course, we did movies. Right? It's array of movies, and I copied and pasted this data into a file that was just movies dot JSON.

I could then tell Cypress to intercept any request to this specific URL and just return movies, And it's gonna know to look in the fixtures folder for movies in a movies dot JSON file, and it's just gonna return whatever in that file.

So it basically would step in the way and intercept any of your HTTP requests so you don't have to hit those real APIs.

So in the course, that's actually what we do is, like, okay. We teach you how to get it working with an API. Right? And then okay. Well, we don't always wanna hit that API. Why? APIs have limits. It's slower. It's gonna cost you more to run it in a continuous integration, so mock it. Okay. Well, how do you mock it? You mock it by creating an object of the data it expects to return. Then with a one liner, you just say, intercept this request or any request to this URL, return this data. And then when it's running, your mock data just pops in there. It's really neat. There's also, like, a GraphQL mocking and intercept too, but I have not used it yet. And this could sound like a a paid tool. Cypress is free. It's free to use. It's free to do anything with. In fact, I have never paid for Cypress at all, and we use it very extensively.

There's also Cypress. How do they make money? Well, they have a a dashboard tool. It's It's called Cypress dashboard, and, really, what it does is it, like, logs and categorizes your test. It lets you know about, like, some tests that Fail. They call them flaky tests where it will run your test several times, and if a test passes one time but fails another time Oh, those are the worst. Then it will Determine that that test is flaky because it's not reliable.

Yeah. It will also give you, like, a the video of all the tests happening or Screenshots of all the tests happening so you can debug them really easily. You could see what's going on. Let me just tell you, man, Continuous integration and testing is like, when there's a problem with the workflow, it's just about the least fun thing for me because it just You just kinda look at it and you say, okay. They failed, but they're they're all passing locally. I've never seen this error happen before. I have no idea what it's doing. So with this, I at least get, like, a video to show me, oh, it looks like one of the EMV variables didn't get set. Oh, that makes sense. None of the movies are coming in. Yeah. Being able to see what's happening. Yeah. It's like, oh, yeah. It didn't load that thing or or whatever.

There's an error in the console being like a course issue because it's running it on a different domain than local host. Believe it or not, debugging is easier When you can see the product as it's being used because it's actually being used. Imagine that. Like I said, I I'm not I'm not one to really love testing. So to have a tool like this is pretty big for me. And any of the things or doubts that I've had about it, I've been using it, like I said, for a long time at this point. Any of the doubts that I've had about it have gone away over time, and the ecosystem is huge for it. There's a huge amount of plug ins. A lot of people are doing Visual regression testing with it where it takes screenshots and then does visual diffing over the course of the time while it's doing your test. I don't do that. Is that built into Cypress, or do you just get the screenshots from Cypress? There's just a ton of plug ins for it. So Oh, so it's just a plug in? Yeah. It's Just a plug in. And another plug in that we use is the dark mode, which is nice.

Gotta have a dark mode. Right? And what are some of the other cool plug ins? There's there's There's some really interesting stuff. There's, like, an accessibility one too that allows you to, like, visually confirm that you have color contrast and everything as these tests run on your actual website in the browser. So that's nice to have another alert or alarm bill going off outside of anything because it's you know, as the site is loaded into the browser. But that's pretty much all I got on Cypress. It's pretty easy to get started with. You install it as an NPM package.

It runs once.

It creates some files for you. You write your test, and it gives you, like, a folder full of, like, 20 different kitchen sink files that are everything you ever need to know about Cypress.

So if you just, like, install it and look at the kitchen sink files, it puts them all there in an examples directory for you. If you're like a Code learner, not a documentation learner. Yeah. You can just paw through those kitchen sink examples and really get everything you need to know out of it. That's sick. Man, I Started this on my site years ago, and I never actually ended up finishing it. And now you got me all excited about getting it going, which Excited about testing is not something that I usually get. Yeah.

So this is really cool. If you need tests in your site and you wanna just Have it in there. It's really awesome to just do, like, even, like, a tour. I call them tours where you just click through every page just to make sure every page loads. And, like, just having something like that, it's Pretty low cost to code up, especially with something like Cypress. I had so much grief with using different React testing libraries, not like React testing library specifically, but how does a TSX work with the testing library, work with the versions of Node, And then I have to compile it through Babbel even though our front end's not ever being compiled through Babbel anyways like that. I'm getting so far away From what I'm actually shipping, that the tests are completely useless at that point. So I just dialed it all back and was like, alright. We're gonna keep it Cypress only. It's gonna be well, Cypress only for the UI. We're still using just on the API.

So for me, it's been a a very positive decision, especially for our sanity overall, And, just made me feel really good about writing tests for the 1st time in a long time. Beautiful. Alright. Thank you so much for laying down that wisdom. Hopefully, you enjoyed that. Anything else to add? I I don't give it a try. At the very least, if you install Cypress, run it once, and then check out some of those files that it gives you, it's It's pretty eye opening, so just give it a try, especially if you're the type who's afraid of testing.

But that's it. Alright. Thanks so much for tuning in. Catch you on Wednesday. Peace. Peace.

Head on over to syntax.fm for a full archive of all of our shows. And don't forget to subscribe in your podcast player or Drop a review if you like this show.