Slow down to speed up. It’s an important mantra that, at times, might feel daunting to put into practice. But learning how to use tools to test your web development can lead to better, more stable products that are less prone to generate panicked phonecalls late at night when your boss discovers your shopping cart checkout button has stopped working. Jessica Sachs is with us this week to look at how one such tool – – makes this process easy and scalable.

Followup Resources


The following is a machine-generated transcript of this episode. It will contain errors until it has been reviewed and edited, and we apologize for the difficulty that may cause for screen readers. Do you want to help us speed up our transcribing process? Consider sponsoring an episode.

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 with the infamous Jessica sacks. I am your host, Michael Fienen.

I’m your other other host, Aaron. How you doing, Michael?

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.

We’ve had rain almost every day for the past week, which has been great because I’ve had to water my garden and all, but it is not warm. It’s like maybe 60’s here. It’s nice. It’s just but it’s not warm

Last week, it was 46 here.


where are you at


Okay. All right.


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

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

You can also connect with us. If you don’t want to do about design grants, you can connect with twitter and instagram dot com. Uh and facebook dot com, but twitter and facebook are slash junkanoo X. And instagram is drinking the ex podcast and also a drinking two X dot com slash discord.

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,

it’s sort of a screwdriver. It’s like a fancy screwdriver. It’s um vodka and triple sec with orange juice. So like a triple sec kind of smoothes off the vodka. Orange juice boundary.

I thought you just, you left the pulp in.

No, now it will gross. What?

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

we can agree to

disagree. I don’t want the Pope, you guys can have it. I’ll mail you guys by Pope. Chew my drinks.

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.

Yeah, he’s he’s more than a mixologist. Um He does, we do okay, So this is how extreme it is. We do a home cooked thanksgiving, but it’s all duck because he doesn’t like Turkey and he will do 12 courses for 25 people of gourmet duck based thanksgiving foods. it’s insane. Anyway, he also makes me margaritas, so I’m around martinis, so I’m drinking a very dirty martini,

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

duck in the martini though. I wouldn’t be surprised if he would make a drink with duck fat and it would actually be good, like it sounds disgusting, but he would make it work

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

he would make his own salt out of it. He’s bad

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

view you mean? View view? We got Js right,

Yes, yes. Right, okay.

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.

Yeah. So, um, so I fell into testing. I was very lucky, I was a high school dropout and in a very small town in northeast florida. And my uh, my mom happened to know A ceo of a small, small start up, 12 people And basically one day it was actually January one because I know that it was technically a holiday. And I started there when I was 16 testing iPad apps. Um and from there I convinced my coworkers to teach me how to code basically.

Um I got a really good education and manual QA testing for about three years um And and automated testing that I wasn’t able to put that into practice for a while. Um At which point I was like I’m done with Q. A. I want to be a developer. Um And I you know, got to join intent um as QA actually and then they flattened everybody into engineering. So it was they flattened tech ops they flattened QA they flattened data science.

And so everybody became a software engineer at your various levels. And that gave me the opportunity to like start coding, coding on features instead of contesting. That was that was like Saga, you know, chapter one, Chapter two was like, I got really involved in the view community after like five years, six years um of being a software engineer and I started, you know, a year into programming View um I started getting into the community via Discord, so like Vue Js Discord is amazing place to learn.

Um and then I started speaking publicly at which point I got scouted. Um so yeah, a mere um he was the head of DX at Cypress was looking for somebody for component testing and he was like, oh maybe the View, maybe the Vue Js uh testing you tills maintainer would be interested in in building component testing for view for Cypress. And I was so I jumped over there,

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.

There are three, there are three maybe four categories of testing that people usually do right? You have your unit tests, components and E. T. Tests. And the best way I can explain it is um is using a resource called the testing pyramid. So wherever you drop links I’m sure you should you should drop a link to the testing pyramid. Um but the way you can explain it is unit tests tests the smallest bit of code.

So like a function that is called AD you know it has one small little job and you can clearly test that and if it breaks you know exactly what’s wrong right? You’re like the ad function subtracted instead of added. That sounds like a problem. Um And as you climb up and up the testing pyramid towards the top your tests become slower because they’re testing more and so you get more bang for your buck. So component tests would be the next layer up.

You might also call, you might also hear them called integration tests that as you climb up and up your test gets slower and which means you get more bang for your buck. You test more things with a single test. So your ad function might turn into let’s say a button and a text field. That as you hit the button, increments might add some numbers to this text field. And so your component test would test, oh, am I rendering the result of add onto the page?

Right? And so you’re starting to climb up from your ad function all the way to the to the browser layer. Right? Am I rendering it right? And at the tippy tippy top, it’s like when I go to the homepage there should be an add button and when I click it it should add everything correctly. And so you’ve climbed to the top of the pyramid here, you’re testing a ton of stuff. You’re making sure you’re like homepage renders right?

All of these other concerns that your unit and component tests skipped over because they were not important to testing. If the ad function worked correctly, worth it would render at all. So that’s that’s a very T L. D. R. On the testing pyramid.

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.

God yeah, everything the browser touches could be yours. Yeah, so so Cypress is pretty cool. Um it was tailor made for end to end tests and so everything else is easier to do right. Um It’s power is in the fact that it can test things that are rendered in the browser so it can load your whole web page on production. You don’t even have to host it locally, Right?

If you’re a QA engineer for google dot com and you want to test that google works, you can load google’s I frame and make sure the search box works as expected. Right? That’s the highest level of the end to end tests, literally testing institute in staging or production. But Cypress being that it just runs code in the browser, can actually test all the way down. Right. And so if you have some function on a module that intends to use a browser api right?

Like I don’t know uh cookies, right, document cookie. Um Cypress is one of the only places that can test that, you know, just actually just for all of its speed is lacking a browser environment. Anything that you do that’s um there’s a piece for animation, like request animation frame anything where you’re navigating a page to and from just can’t really help you easily.

And uh in Cypress can so Cypress is really the browser run time for testing anything browser based. Um so it’s built for end to end in the in the beginning but it kind of did the hard thing at first. Right? And to end is the really hard problem and everything else is pretty easy.

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.

Yeah. Yeah it’s um it feels really natural. So when I when I explain component testing right? Which is the easier version of end to end testing. It’s more tailored towards front end developers that work in react Vue angular when I explain component testing to people, it’s like you get to have all the tools you’re used to in the browser.

Like you can just debug your tests like you do your actual code and that’s such an aha moment because just requires all these nodes specific um utilities to debug and write your tests and it’s a pain in the ass right? You have to learn this entire new tool set, right? Just to get the same thing. You already know how to do in the browser, right? You know how to debug your code when it breaks in the browser. And um that’s what I love about Cypress is it’s just your normal workflow.

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

a longer answer to this. But

I just want to interject and say, I love writing

tests and I love

having test coverage.

And I consider it as just part of the cost of doing business as a coder. So jess you go ahead and


everybody gets shocked when I when I say this, but I hate writing tests. I hate writing tests so much. Um but it’s it’s necessary, right? And I I’m not zealous about test driven development, which is a very common workflow that you’ll hear about if you if you google for how to do testing. But I really don’t like testing. And so I want to, I want to get most of it out of the way very quickly and I don’t want it to be a pain, right?

That’s my those are my motivations as I want it to be easy and I don’t want to mess with it very much. Um so you have to do it because you need to not break things right. You need to make sure that your code will ship to production and you won’t get a call at 5:30 p.m. On friday saying, hey, by the way you broke the checkout button, like that’s bad, you can never break the checkout button, don’t be in the way of your company and money.

Um, and that’s, that’s actually what Cypress is for is literally those most important paths of like people can sign up for your service and log in and pay you money by adding products to the cart. Like the most important stuff should always be covered if somebody is starting a brand new project. Um, as soon as it starts getting users, you need to write an end to end test. You can forgo unit and component test. So long as you know, your checkout flow works basically

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.

The example that really clicked for me with keeping a testing framework was on a work on the rails app and um I was just learning how to write tests and they were a real pain in the ass and I didn’t like writing them and I didn’t understand why I had to do those extra work. Um, and then one day I was making, adding a new feature and I change that. I made broke something on a totally different part of the app because they happen to use like the same shared library area.

And I didn’t know that it was over

there, but I wouldn’t

have known about that had it

not been for the tests. And I think the thing to remember what testing is that your app is going to grow and get larger and it’s kind of ridiculous to think that you or maybe you can because you’ve been with it the whole time, but new people may not know about that. And so having the test there really helps to kind of be the it’s like a safety net for when you’re making changes to having features and things.

Yeah, I think when you, when you start new code and it’s it’s more than a hack, right, If you’re doing production level code that will, will go out into the wild, you should always be writing tests alongside it. Um I won’t I’m not zealous about if you do TDD versus if you do them before your pull requests, I think for new people it can be helpful to do TDD first.

You should at least know how to do it because sometimes you need that framework when you’re working through a particularly tricky,

Could you give a 32nd explanation of TVD?

Yeah, So test, test driven development is also known as the Red Green re factor loop in that you should define what behavior you’re looking to get. So um looking at let’s say an AD function, you expect to pass one and one into the function add and that should return you the integer to. Right. So that’s the most basic example. But if you’re going to look at a more complex thing, right?

Let’s say you have a form which is, I’m going to fill out the form, so I’m going to get the input fields, I’m going to type into them and I’m going to hit submit and it should, you know, if I do it wrong, if I’m testing the negative case of invalid email, it should spit out an error at me. And so that’s kind of how I would t D D. A visual thing, which is actually something people really struggle with is how to think about things that are more complex than ad.

I think the thing that’s may be counterintuitive about TDD is that you’re writing before you write any actual code, you’re writing a failing test first,

that will

pass when you have the code written correctly. Um And that’s really, really awkward,

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’s a really good entry point. It’s like the perfect time to do it too because you can always, you don’t even have to fight for why you’re spending the time because your product manager or tech lead has just suffered why that bug is a big deal. So you don’t even have to explain it, right? You’re just like, oh, this is issue number, whatever. That just broke these things and it was a pain in the ass in these ways.

Um, my in Cypress, so Cypress itself, right, is an open source project and we have one of the beefy ist test suites that I have ever seen and even when joining Cypress, I was like, this is excessive, but you have to think about it, right? Like what tests the test framework, like we really have to be on point having bugs is really can be dangerous, right? People rely on us.

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.

Yeah, I mean, so literally right now we’re building an architect and component testing, which is like, it’s essentially almost a rewrite of a lot of Cypress. Um but the number one thing we’re concerned about isn’t how it looks, but the fact that it can always give you the correct answer, right? Like any flake, any mystery, like misreported result is like a business killer I would call them is like, it’s pretty bad. Um, we don’t really have them. Thank God.

Like Cypress is very good at making sure the things that are broken, stay broken um are correctly reported is broken. But you were talking about bug driven development and I wanted to say that in Cypress in particular, we have many tests that are just called their issue number on Git hub. Like it’ll literally just say like hashtag issue number 11,000, whatever.

And uh and then you can, like, somebody will put the pr link in the comments at the top of the test and you’ll open it up on get up and be like, okay, I see, I see,

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.

Yeah, yeah, I’ll do

that sometimes. If I if I write a test just to kind of um proof of concept that I fixed the bug, I’ll just throw like a this is for issue number, whatever. Um this does a reference and maybe providing a little bit of context because especially if it’s a bug you think could happen again. It’s nice to know that mike we’re going to be notified if it comes up again.

Yeah, for particularly serious issues, it’s a must like testing is testing is really like a sliding scale of importance, right? You, you don’t have infinite time. So you have to make sure you test the most important things at least right? You can make your story. You know, you can, you can take a day to implement the feature and a day to write the test.

But if you’re, if you’re going overboard, right, if you’re testing all the things that could possibly break, it’s a, that’s where, that’s where people get really confused. Honestly, they’re like, how much do I test? Um, but testing the most important bugs, testing the most important bugs is like a very good idea.

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

testing is documentation. You were you were talking about BDD is bug driven development but the other the other meeting of B. D. D. The classical meeting, quote unquote classical um is behavior driven development. Right? And you should, the way you can think of it as your test should look like english. Um And so you’ll often see tests written in the BDD style um if you come from ruby you might be familiar with Capybara um which is like I use

that all the time.

Yeah. Yeah and it’s um I honestly think that they’re interchangeable. Sometimes you just want your tests to look like english because it makes more sense. But but as documentation right you can read your specs and it would say like when the user clicks submit it should throw an error if the email contains an emoji right? Which I think is actually valid now. I think you can put emoji in your email.

But um but yeah your test would re like english and then at the end of it um there are reporters that do this at the end of it. You can generate like a list of requirements off of your test suite off of your BD test suite which is I’ve never seen it done well but in theory you can do it.

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

that would be really fun.

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.

Yeah you could you could know javascript. I mean to write your tests you need to

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.

These are called domain specific languages. DSL s um respect, respect is one that’s why I know the term.

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?

Yeah. So these are these are general concepts by the way, these aren’t specific to Cypress. Um So the assertion library, its job is to let you um Mhm. Act on what’s called a subject and make sure that the subject behaves as expected and it allows you to be specific about what your things should do, what your subject should do. So there’s um there’s simple ones like expect one to be equal to one, or expect one to be less than two.

Those are some based ones that you might do with numbers um or expect, you know, foo bar to contain fu right to contain the string, foo. Um So those are those are your basic building blocks. And then Cypress gives you all those basic building blocks and its assertion framework, but it also packages together some dumb based assertions.

So when you’re testing websites, you care about if elements are present or not, you care about if you can click on things and Cypress gives you the basic building blocks. Um And so that’s that’s packaged in there’s an assertion framework called chi right often used with the test runner called mocha. And so chai is the assertion framework that Cypress uses.

Um If you’re familiar with jest and jests assertions, chai is just if you put dots instead of uh instead of camel case for your expectations. So like to be equal would be you know, instead of instead of having dots between it, it would just be just be camel case, but they’re basically the same thing. They accomplished the same purpose, assertions. Just make sure your things do what they’re supposed to do

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

and it’s just a function, right? Should have length per ends like literal parents as a function for right? As a number. And that will build your little uh little expectation. And that’s what if you ever run a test framework in the terminal, that’s what prints out the little check mark that says Yeah, it worked. Is when you do an expectation inside of a test, it’s like good job it passed.

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

just Cypress and you can actually, you can do MPX if you feel like NPF Cypress and that’ll just do the whole thing. Um Yeah, but N P M I G um Cypress, that’s the that’s the shorthand, there’s some dashes in there and definitely some spaces

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

you did api testing with it.

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

Most most people don’t get to aPI testing but it’s actually a damn good tool for it. Um Yeah. Well you discover it beautiful.

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

mean like you want to organize your tests like your application is structured, right? It should be a very easy way to think about your application. If you have a cart folder, you might have a cart folder inside of your integration. Sweet. Right. You might organize things literally the same way your source code is organized.

You may just order them by ticket number. Yeah

We have we actually number ours from 0-9 and we use uh we use circle see eye to paralyze them. It’s actually weird stuff you can do with it. That’s a very weird use case but you can can do all sorts of fun stuff. It doesn’t matter how you organize it.

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.

No I mean you have to configure it so you have to you have to configure it with some pattern or it will take spec as the base pattern. So we have a little config files, Jason files, it’s at the root of your project which is probably you know the root of your Git directory. Um It’s called Cypress, Jason and it has a has a field called like test path pattern or something like that.

Um And you and you fill in the little glob string, right same thing you would do on a file system to select multiple different files. Um And that thing will find whatever you tell it to find. So so

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?

You can it matters. Um so you can just say it. And my my actual basic file um is really just an IT block where the title is works and I expect True to be true. And that’s the first thing I ever write in and expect that but in the navigation example. Right? We have four links. We want to make sure it’s four links. So we’re going to describe navigation at the top level.

We’re going to go inside the described function make a little IT block what we call them if blocks um and we’re going to give it a string that’s like it should render for things and inside the IT function, you’re going to the body of the IT function, you’re going to write your site commands.

Right? So it would be like sai visit local host and then you would say get the knave bar maybe with some selector selectors are like if you’ve ever used document query selector all or document get my idea. It’s actually the same sin texas. J query. So if you’ve used j query the same thing or what

is it? Somewhere like CSS.

Exactly. Yeah literally. Yeah.

Example hash nav space Ally.

Yeah. And that’s how you would get the if your nav had an L. I. Right? That’s how you would get the four elements inside the inside the nav right? And so you would get them and then assert should have length for and that would be your test, it would be like three lines long.


four lines long.

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?

I mean, it depends on the so it depends on the scope of the test you’re doing if you’re doing a intend test or integration tests with Cypress, it’s really it’s I say really slow comparative to uh to unit testing. Component testing and to end tests are fairly slow. You know? Let’s think about the testing pyramid. It’s at the top right? Which means that it’s the slowest but gives you the most test coverage. Right?

And so, and to end tests, you would run them, you can run anything locally, you can run anything locally you want. And generally when you write a new test, like what we just, did you run it locally, you say N P X Cypress open or N P X Cypress run and I’ll talk about the difference of that in a second. Um, and that would invoke your tests and then you would make sure that you visit local hosts, your Nav bar has rendered and you have four items in it.

Good job, you get the green checks at the end in your terminal, right? Um, the immediately after you’re going to want to hook it up into ci because it takes a few seconds. Right? So you can keep it up while you’re working.

If you if you’re going to run a lot of end to end tests, depending on the kind of work you’re doing, um but mostly, and even in Cypress internally we add our specs, you know, we maybe run some that have changed, but then we just run them in ci because for any reasonable test suite You will very quickly get annoyed by waiting 30 seconds or so.

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.

It’s good to think of them as sort of like data macros, like it’s you know, you know, this is a chunk, this is a block of like good data. Like this is a happy path, real user trying to do the right thing, fill out the form and you don’t have to think of it every single time. You know that this data is good. So you’re just going to reload the same cassette each time.

I would essentially just literally call it good user in my tests. Like I literally say good user, bad user, invalid email user um in all my fixtures.

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.

Yeah, it’s an insanely powerful framework. Even me, I’ve worked at Cypress for like a year and a half, I guess at this point and I keep finding things, I’m just like, oh my God, they let you do that. You can do all sorts of crazy shit. We, it’s just javascript runs in the browser and you have access to the entire Cypress test runner, you can do basically anything from, we have what are called plug ins and the support file and one of them is node side.

If you’re going to play with your server, if you’re going to see your database for your example, like if you wanted to nuke your staging database between every run, get fresh set of records, you could do that technically might have some, you know, it might be a little difficult to pull off, but Cypress gives you an open door into both the node side process and and a browser side process. And so the world is your java scripting Oyster.

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.

Tell me more

flair with Acts

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,

no it’s fine. I’m I’m half, I’m half a martini and and so I’m like I was going to say something,

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?

April april 7th april 6th. I will forever remember that day because it was so much work. Um yeah, it was, it was something around there and seven dato of Cypress, we released component testing which is a brand new test runner and that’s focused on testing the building blocks of the modern internet. Right? We all think in components now instead of pages.

Um so we’ve kind of migrated away from building giant WordPress J query based apps into building, you know, self contained form components or modal components or inputs. Um these small building blocks and it’s much quicker, efficient or more quick, efficient and satisfying.

I would say there’s none of those flake problems actually when you, when you start to test the building blocks by themselves, the inputs, the forms, um when you, when you start to test the components themselves, a lot of the end to end problems fall away and uh it’s I’m really passionate about component testing, which is why I work here. 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?

Yeah, A unit of code that renders to the screen right? You could use it to test a J query component if you wanted to. Um technically we only have 33 framework level bindings for angular view and react. But literally the job is render render the thing to the screen right, render the form to the screen in general. Like if you were going to use a web component, if you are going to use J query, we don’t care. Just get it onto the screen and we can test it.

Um you don’t even need Cypress’s specific um Actually you don’t need a lot of Cypress specific stuff to pull off component testing um Sabre springs, the automation and test runner for it and the clean up and making sure that you can actually test your component once it gets on the screen. But mhm the basic principles are all very all very straightforward, Get it on the page, click on it and make sure it did what you wanted. Mhm

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.

It’s going to be side on intercept. The most powerful thing Cypress can do is intercept your network requests and give you the power to control them. Uh and to end like you can you can literally define your own express style responses. So you know, a server type response, you have the full control of what your web page, what your application is going to get back. Right? And so that lets you avoid an entire class of mm Okay.

I would say an entire class of bullshit right? You just don’t have to deal with its um any flake you have with your back end service. If you get annoyed enough with how slow your back end services and it’s still messing up your tests, go ahead and stop it. You don’t need to rely on anything else. But cypresses tests to create your environment so side on intercept

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.

Yeah and it might actually be problematic right? Like some some production A. P. I. S. Don’t really like it if you hit there if you hit their stuff during test mode right? It’s not it’s not great they kind of count that towards your towards your monthly quota, depending on the service. Mhm.

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.

Yeah. So so you can find me on twitter mostly. Um I’m sure a link will be posted somewhere. Um May God twitter dot com slash underscore Jessica sacks. Um And I tweet way too much. Um I. D. M. S. Are always open because I I like to help people um And if you want access to the Cypress, um I was gonna say support team, that our support team isn’t actually there.

If you want to, if you want to have access to uh Cypress team um to talk about testing, to learn about what we’re working on, we have a Discord channel um and that’s the best way to the community. Yes, the Cypress Community Discord. Very nice. Um if you want access to that, you can just go on on dot Cypress io slash discord. So that is on dot Cypress io slash discord. Uh That’s the best way to talk to any of us.

Yeah, I suppose some other things if I wanted to, if I wanted to get people started on stuff or give a shout out, I would say my teammate Lachlan Miller has a really cool Youtube channel where he does everything from, you know, create a test framework from first principles, so not Cypress specific, but all of the concepts we just talked about, he’ll go ahead and uh, and work through that step by step and talk about how to build an assertion framework and he’s, he’s really great, um, cannot recommend lock and stuff enough. Again, I’ll put a link wherever you can find it.

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.

So, yeah, that’s uh that’s where you can find me and Lachlan stuff is my number one recommendation for anybody looking to learn more. And he’s doing really good stuff.

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.

It’s kind of funny to imagine you’re

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 real,

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.