JavaScript Marathon: End-to-end Testing with Cypress

hello and welcome to javascript marathon presented by this.labs we are thrilled to be bringing you a day full of training my name is tara hampton and i will be your host today are you looking to add testing to your skill set or just feel confident um pushing to production well you're in luck in this session we'll be walking through the process of installing configuring and writing a critical path test using cypress training you today is cecilia martinez cecilia welcome we are so happy to have you here today um cecilia is a success manager at cypress and a volunteer with women who code front end and out in tech atlanta if you have any questions or comments after today's session feel free to reach out to her directly on twitter at cecilia creates also shown in the bottom left-hand corner of the slide there on your screen she's also going to be having some fun interactive um stuff throughout her presentation and that you're going to want to pay attention to so make note of that that twitter handle for later you'll be glad that you did and of course we couldn't do this without our sponsors our sponsor today is the stat labs your partners in modern digital transformation specializing in mentorship consulting training and staff augmentation for enterprise organizations you can find out more at this.labs.com or send us an email at hi this dot dot co do you find keeping up with the constantly evolving technology is a struggle do you want to bring your team up to speed on one of the latest technologies this dot labs offers personalized training programs to suit your organizational needs ensuring you and your company stay on the leading edge contact us today at this at hi this dot dot co to set up your complimentary needs assessment and if you're familiar at all with this dot you may already know that we put on weekly meetups online covering various frameworks and topics this dot's online meetups are an amazing opportunity for developers and enthusiasts alike to engage with the global tech community no matter where they are in the world for the latest schedule and links to join go to this.co and on that note cecilia i am going to kick it over to you again thank you so much for being here we're very happy to have you yeah thanks so much for having me very excited to be here so yes i am cecilia martinez going to be talking to you today about end-to-end testing with cypress if you would like to follow along or code along this is the address to the repository that we'll be using today it is a fork of our cypress testing workshop uh specifically made for this talk so it's kind of a taking a full day workshop into one hour and so that's what we'll be covering today so you can go ahead and take a look at that repository if you'd like to follow along or check out the examples that we're going to talk about okay so like i said i'm cecilia martinez i'm a success engineer at cyprus i am based out of atlanta georgia i am a volunteer with women who code front end i'm a track evangelist and then additionally i'm also on the out in tech leadership team and a founding member of the atlanta chapter of out in tech which supports the lgbtq plus community in tech you can get in touch with me i am cecilia creates on twitter and github and you can see i also have my handle on the lower uh right hand side of most of my slides and and then additionally i'm also on github at cecilia creates all right so uh i do want to before we get started um talk about we're going to be having a couple of opportunities for participation today so throughout the presentation i'm going to ask some questions and if you could throw some answers in the chat if you think you know the answer i'll be picking uh some of the responses to send a sticker pack so i have quite a bit of a wide variety of stickers from attending different conferences and just kind of all the different meetups and volunteer groups that i organized with and so kind of wanted to share the wealth so if you need some stickers for your laptop or anything like that keep an eye on on some of the questions and those opportunities and make sure that you throw those in the chat and now and once if you do get an answer question correctly and you win a sticker pack just uh please reach out to me either on twitter um or you can also yeah on twitter the best way send me a dm and i can get that set up for you all right so let's go ahead and start talking about uh well you know what cyprus is so cypress is a testing framework it's javascript based and it's for anything that runs in a browser the test runner is free and open source so you can always take a look at the source code online on github like i said the cypress runs in a browser an actual browser alongside your application code it has built-in library so if you're familiar with mocha chai and jquery selectors those libraries are built in to cypress additionally it has built-in weights and retries so if you've used other end-to-end testing frameworks uh you essentially what's happened sometimes is elements take too long to appear on the page or an api call might be taking a little bit longer than expected and tests could fail when really there's not actually a failure with the code base so cyprus has built-in weights and retries where it will allow for a certain amount of time to pass for an element to appear or for a route to resolve or request resolve before failing the test additionally the test runner has a lot of different features that make it helpful for a debugging test and when you're writing tests there's a time travel feature that allows you to click through each step of your test and see what the application was doing at that time it also has very detailed error reporting that allows you to click right into the line of code that caused the test to fail additionally there's artifacts like screenshots and videos to allow you to see what what's causing test failures and what your application is doing during your test we have some great documentation and we also have a because we're open source we have a lot of community plugins and there's a lot of different integrations that can be utilized and leveraged with cypress and there's also the optional cypress dashboard if you are looking to leverage parallelization for your test runs additional analytics and integrations i wanted to share some resources to help you learn cyprus so we're very community oriented we have a lot of resources that we make available for anyone to use like i mentioned before we have our cypress documentation there's multiple sections to our documentation we have a really robust guide section this is only a small list of the guides that we have available additionally we have the actual documentation for our cypress api which includes all of the commands for our api we have examples and recipes we have our plugins and then we also have a frequently asked question we have our cypress real world app this is actually very exciting it was released pretty recently i did a talk on this um last week but the cypress real world app is a full stack react application it's like a venmo or paypal and it allows you to see cyprus in action on a production level on a production level app and allows you to learn tinker experiment and practice and get an example of what some best practices are so definitely recommend checking that out additionally there's a link to the cypress repository on github we have a getter community chat we have a cypress blog and then i also like to plug gleb our vp of engineering has its own personal blog that has a lot of additional resources on our documentation we do have a search functionality it looks at recipes our kitchen sink examples and then also our blog posts so it doesn't just search the documentation it also searches additional resources and then i wanted to point out this url so with our documentation if you do on.cypress.ioslash and you type in an api command so whether it's you know click or type or get or request it will take you directly to the page in our documentation for that command additionally you can also try searching for certain queries so you'll see some of these links throughout the presentation but in some cases you can also search topics like code coverage or like writing organizing tests and use this format and it'll take you to that section of our documentation okay so time for the first question and um so everybody get ready get ready so if you think you know the answer hopefully you do uh you can throw the answer in the chat so true or false uh cyprus emulates a browser to run your test so we'll see if we uh so again if you know the answer feel free to throw it into the chat to win a sticker pack so true or false cyprus emulates a browser to run your test and uh all right so i'll let y'all answer that question in the chat whenever you get a chance and whoever wants to grab a sticker pack just go ahead and throw that comment in there all right so and i will go ahead and answer that a little bit later on once we get some responses all right so we're going to take a look at the application we're going to be using today to run through our code oh wow look at this okay we got some answers um yes so the answer is false it looks like um got quite a few uh responses but the first one is the magx777 so if you could send me a dm on twitter i'll get your sticker pack and that is yeah so the answer is false cyprus runs in an actual browser and we currently support um chrome firefox and then microsoft edge so chromium-based browsers and firefox so your tests run in an actual browser not an emulator so that means that you're going to see what your app does in the real world in your real browser environment and it allows you to see true behavior okay so going back to our application uh we're going to be using like i said it's a fork of the testing workshop cypress repository it's a to-do app yay i know y'all are all very excited about this um and you're probably very familiar with to do apps so it's a view and rest server application and app functionality like as you can probably guess you can add tasks toggle tasks complete and you can delete tasks so we have open here it's just running locally local host 3000 and this probably looks very very familiar um if you've done different types of tutorials and things like that so this is the application that we're going to be working through today and again you can access it from this github repository the branch that we're working on is specifically called js marathon all right so if we're getting started so like i said if you'd like to follow along or if you're watching this later and you want to follow along with the repository you could essentially go to this github um and you would go ahead and clone it so you start by cloning the repository cypress io slash testing workshop cypress you would cd into the actual folder once you clone it you would run git fetch and what this allows you to do is it allows you to pull the branches that are at the origin that you don't have locally because you're going to want to check out the js marathon branch and then finally you can npm install in the and that will bring in all the dependencies one of which is already cyprus so again if you're following along you want to use the same repository that we're using you want to clone it fetch check out the branch and then install if you're not only longer if you're starting from scratch this is how you install cypress on your machine so in the root of your project directory you can use either npm or yarn but it's npm install cypress or yarn add cypress and you just want to save it to your development dependencies as a best practice i did want to mention that there's we don't we don't have a global install option and we don't recommend that because the configuration should really be specific to your project so if you have multiple different projects you're going to want to have cypress installed in each project in order to have that configuration okay so after you've installed cyprus the first step is to run the command to actually open the cypress test runner so you can use again you can use npm or you can use yarn but in the root of your project directory you'd run npx cypress open or yarn run cypress open so if you're running this for the first time in a new project there as few things are going to happen you're going to see to terminal command that validates that cyprus can run on your machine it's going to add a cypress folder to your project and it's also going to create a cypress.json configuration file again if you're using the repository for this project that's already included however you're starting from scratch this is what's going to happen when you when you first open the test runner so i mentioned that cyprus will automatically create a cypress folder in your project repository this is the structure of that folder so it contains a fixtures folder that allows you to store data that you want to access during your tests so for example if you had a list of users like username and passwords that you want to be able to use to log in if your app has a product library or a product catalog and you want to be able to access that data you could store it in this fixture folder in the integration folder is where we actually store the tests so if you're opening it from scratch you're going to see an examples folder with a wide variety of our what we call our kitchen sync examples that allows you to click through and run some example tests in this case we have one test file because we're doing a critical path test and so that's the criticalpath.spec.js file you can also use uh you know just node.spec you can just use js or you can use ts as well and then there's the plugins folder which has just an index that allows you to set up plugins if you have any for your project and then there's a support folder which essentially contains any kind of commands that you want to run when you're up when you're running your test and then you can also create custom commands which we'll talk about a little bit later on all right so taking talking about the cypress configuration file there is quite a bit that you can do in here i wanted to point out two specific things as a best practice we recommend setting the base url or your application in the cypress.json file this prevents you from having to type out localhost 3000 every single time you want to visit your page so by setting it in your cypress.json configuration file it'll automatically uh prepend or it'll put put that url in front of any additional pads that you might designate in your test code i also wanted to point out that we're setting a viewport width and height to run our tests in so there's a lot of different options for setting your viewport you could do it dynamically within your test you can do it in a configuration file you can also do it by passing environment variables in this case we're just we're running a single test and i wanted to essentially have it be a consistent viewport whenever we run it so that's why i'm setting it here in the configuration file all right uh taking a look at test structure so if you um if this looks familiar you probably know the answer to this next question so here's another chance to grab a sticker pack so get your get your chat fingers ready so what test runner library does cyprus have built in so i know there's a little bit of a delay so let some answers come through before i answer that so while that is coming in i wanted to point out what our test file actually looks like so this would be an example of one of our you know critical path spec.js files up top we have where we're pulling in our reference types of cypress so what this does is it brings in intelligent code completion and intellisense for your vs code so highly highly highly recommend doing this in your test file so that you have access to all of the commands and information of the cypress api it's very robust so we'll be taking a look at it okay so we're getting some answers so yes rob martin coming through with mocha so if you like i said if this looks familiar it's probably because you're familiar with mocha which is a test runner in a way for setting up tests so i'm just going to rob martin if you want to send me a dm on twitter i'll get your sticker pack so when we take a look at this that's where this these words uh describe before reach and it come from those are those are called this comes from mocha and that helps us organize and structure our test file so we have a describe block is essentially how it's called and that holds all of our tests typically you want to categorize or you know contain your your tests based on certain categories so in this case we have one critical path test so it's just says our test but that's how you essentially contain all of the tests that are going to be running together there's a before each this is called a hook so mocha has some built-in hooks you have before before each after and after each what before each allows you to do is it actually runs before each test so if for example you needed to reset your database or you wanted to visit a cert your home page or you weren't you needed to log in before each test rather than having to hard hard code that individually you can put that in the before each and it'll run automatically in between every single one of your tests and then finally we have our test blocks so you can have multiple it blocks within you know your describe so you can have multiple tests that run within within your spec file i do well want to comment that i like to use describe and it but if you prefer context or you know the kind of the other format when using mocha that's also built in and you can definitely use that i just this is what i'm used to so hopefully that's not too uh too confusing for anybody okay and again oh yes i wanted to point out on the the url here this is using one of those on cyprus links so on.cypress.io slash writing organizing tests takes you to the section of our documentation about writing and organizing tests pretty exciting so just a little bit more about test structure so we talked about what the actual code uh structure looks like for organizing your test but what is actually what what kind of steps do we walk through when we're doing our tests first things first we visit the page right so we can actually we can't test our application until we're on our application and so that's always the first step is visiting our application then we typically query for an element and so you know we for example we may want to grab the header or grab a button or an input that we need to action on once we have that element we typically perform a command so if you think about what your user would do if they go to your home page and they click on a login button you know that the clicking of the button would be the command and then we make assertions so when your user goes to your home page they find that login button and they click it a few things should happen right they should go to a login page or there should be a model that pops up or it should allow them to input their username and password so we make assertions to ensure that what we expect to happen is actually happening and then finally we repeat as needed so with end to end testing it's not like unit tests so we're not testing very specific units of functionality we're not testing individual functions for anything really testing components we're testing the actual journey that your user goes through so you can repeat these steps as many times as needed throughout a single test okay and so let's go ahead and dive into the cypress api basics so we're going to talk about some of the cypress terminology we do try to keep it as english syntax like as possible to make it beginner friendly we have people that have no javascript experience at all and are able to get started with writing tests with cyprus because of that so let's take a look at what some of the basics are of the cypress api so all of the commands start with psi cy psi dot get and psi dot contains are essentially our two like most common selectors so if you think of side dot get as like query selector it works the same way and it allows you to query for a wide variety of different elements on your page sitedoc contains is different what it does instead is it searches for text so if you were to pass psi dot contains hello world it would look for any element on your page that contains the text hello world after the selectors we have our commands so we have commands a wide wide variety of commands we have sign up click and send out type are the ones that we that i use kind of most often there's also sign up check but if you think about the types of things that your user would do that's what these commands replicate so our commands do have built-in actionability checks so what that means is that cyprus thinks of things like your user and if your user goes and there's a button on the page but it's blocked by something or it has a certain css class that makes it not visible then your user won't actually be able to click on it so cyprus automatically tests for actionability with these commands so when you think about things like check uncheck select uh trigger which triggers things like hover or mouse mouse down events it's always going to make this these default assertions so that allows you to make sure that if your test code can do it then that means your user could also do it and that's what you really want is you want that confidence that your user is going to be able to use the application the way that you expect and then after our commands we have our assertions so i know somebody in the comment comments mentioned this and i mentioned a little bit earlier but we are we do have the try assertion library built in this includes both the bdd so the behavior driven development and also the test driven development types of assertions so for this presentation i use should that's just one that i like again you can use expect or you can also use a cert whichever you're more comfortable with and then also wanted to point out i saw that raj also mentioned the chat that we have sign on and we do uh that sign on js is an additional library that's built in that allows you to make some additional assertions so definitely check that out if you're familiar with someone interested okay great so custom commands i mentioned this earlier it's a little bit more of a intermediate topic but i'd like to cover it because i feel like it makes your life so much easier when you're writing tests so if you bear with me a little bit there within your support folder there's the commands.js file this comes automatically however you know by default there's nothing in there except for some information this allows you though to add commands to cyprus that you can leverage throughout your test code without having to rewrite them each time so the first one i want to highlight actually comes from our real world app which i just mentioned this is used pretty heavily but one of our best practices when selecting elements is to use a data attribute so this is an html attribute that's actually put right onto the tag in your code that allows you to grab that exact item so rather than using a class or something that could be brittle and change causing your tests to be flaky or to fail by using a data attribute selector you can get exactly the element that you want and there's no confusion so what this comes custom command does is it adds a command called get by cell or get by selector um and it takes in a selector and it automatically returns our psi.get with the entire html attribute pass through so like i mentioned earlier psi.get is like query selector so you can query by class with a dot notation you can query by id with a hashtag or pound sign you can query by html tag name like you know like li or h1 and then you can also query by these html attributes so this allows you to kind of do that in a quicker way without having to type it out manually each time the other type of command that you can use is an actual command to to perform an action so in this case we have a to-do list and guess what in order to test our to-do list we probably have to create some to-do's there's a way to do this manually you know you essentially would get these item the input and you type into it the name of the to do and you hit enter type no but having to type it out manually in your code over and over and over again can get a little bit tedious so instead we've created a custom command here where all we do is we pass through the name of the to-do and it creates it for us so we'll see that leverage throughout our code today okay so done a lot of talking a lot of slides let's go ahead and dive into the actual test runner let's look at some code so go ahead and open up vs code and just to kind of show you here on the side hopefully this font is big enough i tried to pump it up as much as i could we have a cypress folder so we have our to-do mvc folder here which contains our actual application code then we have a cypress folder and as i mentioned before we have our fixtures integration plugins in our support folder and then of course we have you know if you're familiar with fbs code is your ide and we have the actual test file here i've already started up the application so let's go ahead and open up a another terminal here and we're just going to do npx cypress open to open up the test runner give that a second to open up so this is uh essentially that this is the test runner it's it's it's we have on the top cross sorry about that we have a across the top the name of our repository some links to support in our documentation you can log in if you're leveraging the cypress dashboard however that's not required here we have our test file so we can see it's automatically pulling in the integration folder from our repository and it's automatically pulling in whatever test files it can find and if we hover over this and we see this open in ide button and we click on that it actually opens the test file in your ide and vs code there we go close the terminal here additionally if you have multiple test files you could search for them we only have one that's not a problem this drop down allows you to change the browser that you're running the tests in it'll automatically pull whatever browsers that you have available on your machine so i do not have edge or firefox installed in my machine so that's why they're not showing up however if i did they would be here in the drop down to run my tests so we're today or somebody running the testing chrome again if you're leveraging the cypress dashboard this is where your runs would appear and then we also have the settings so i want to point out the configuration setting here this is pretty interesting because it shows all the default configurations in cyprus and then it also shows where we've overridden them and the source of that override so here we can see that the viewport width and height have been overwritten and that's coming from our configuration file and then we have our base url which is also being overridden by our configuration file but this also shows how else you can override you know you can pass things through an environment file you can pass them through as environment variable when you run your commands and then you can also have things set from ci or plugins additionally on the settings page you have your node and your proxy settings but i wanted to show file opener preference so this is where you can choose which code um ide you'd like your test to open it and then we also have an experiments tab which allows you to set up some of the experimental features that we currently offer all right so if we go back to our test let's go ahead and take a look and see what happens when we click on it to run it okay so that was a test run everything passed good job so let's take a look and see what this looks like so this is the browser that the test runner opens on the right hand side it runs our it shows our application we can see up here in the top right hand corner that we have a viewport of 600 by 800 again that's what we set in our configuration on the left hand side we have the command log so this allows is what shows each and every step of our test and it allows us to hover over and as you can see as we hover over on the right hand side our application is showing what actions to end what things took place so right away you can get a sense that if something fails you can see everything that's happened before then so what does it look like when something fails let's take a look and see so if we go back to our test code i'm not going to go too much in the code right just a second but let's say we change this to to dopes if we save cyprus runs in watch mode so it automatically reruns the test whenever it detects a change okay so in this case we can see that the test failed what kind of information do we get we can see in our test body that the psyduck contains which again searches for text on the page timed out retrying expected to find contents to don'ts but never did it shows us which command failed in our test code and if we click on this it takes us right to that line in our ide and we say oh to don'ts what was i thinking it should be to do's so um another thing that we can do is if we we know this test failed and all the other ones didn't let's just take a look at this test right now so we can go ahead and add that only after our ic block and if we hover over this because of intellisense being pulled in it tells us you know what that command does so in this case it's only going to run this specific test and we've updated here to from to don't go ahead and fix that to to do and we'll re-save we'll run our test again run so fast and this time it passes so it was able to find to-do's on the page i also want to demonstrate our selector playground so if you're in the process of writing tests i highly recommend having the test runner open while you're writing your test because it'll watch for changes you'll be able to see in real time when things are passing or failing the other way reason i recommend it is because of something called the selector playground so if you click on this icon here open selector playground you can actually hover and click on areas of your application to see what selector will pull that so for example we can see here we hover over to do's data sci equals app title if we click on that we could just go ahead and it shows sign get data sci equals app title and we can copy that to our clipboard and put that right in our test file so if you don't have access to your code base or you're not necessarily sure what the most specific way to get an element is this let your playground kind of help you help point you in the right direction again best practice is to use an html data attribute okay so that is the test runner specifically again there's a lot more in here that we're going to dive into once we kind of talk about the test code oh yes one of the things that i did want to show as well is you have access to your dev tools the same way that you do in a regular browser because again this is a regular browser so that's really helpful to view for example our network requests so we have a before each hook here that makes the post request to reset our database so when we run our tests with the with the dev tools open we can see all the network requests that are taking place if we wanted to view any of the responses we also have our console okay that's fine and we can go ahead and click on any of these commands and it'll print it to the console so we clicked on the request and we can see the command was request it has the request body url headers and it has the response as well and we can do this for any of our commands so we can also click on the contains to do and we can see what what element it actually yielded specifically if we wanted to confirm the hdmi that's i'm sorry the html element that's pulling back okay so time for the question and then how can we access multiple variables okay and then um i i will have a little bit of time for questions at the end i know that there's probably some specific questions that people have but i want to be able to keep moving so uh feel free to also dm me any questions that you have on twitter as well and i will take a look at the youtube after to respond so time for the sticker pack question so how do we run a single test in our test file so it's kind of a you know um to talk about this not too long ago so hopefully we'll get some good answers on this one for now i'm going to go ahead and close out the test runner so we can either do that by closing this browser or we can just hit stop and it'll automatically close and we can come back here so again on this slide it just kind of shows an overview of the test runner we have our test status menu which shows how many tests passed how many failed how long the test took we can rerun our tests at any time it has a url preview our viewport sizing the preview of our application and then the command log that allows you to step through each step of the test okay so we took a look at some code we talked about so first we started we're talking about what cyprus is in general we took a look at the test runner and a little bit about what some of the api commands are and how to actually write the tests i wanted to talk about best practices around deciding what to test because that's another question that we get a lot and especially if you're new to end-to-end testing and you're only familiar with unit testing uh the approach is definitely different so end-to-end tests focus on the features like i said before they can definitely be long and contain multiple commands and multiple assertions and then you also would want to examine the side effects of actions so when we think about end-to-end testing essentially what we're thinking about is when someone a user does something is the behavior that happens expected okay awesome certainly gets the i i can tell there's a little bit of a delay so that's um yes it looks like oh becca so becca you win a sticker pack so the answer is dot only so yeah so you would add that only after your it block to run just a single test all right so becca i think we're actually already friends on twitter so feel free to send me a dm and i'll get to your sticker packet so all right going back to uh what to test so yes the approach for end to end test is different than unit tests and you it's really important to what the actual end user's workflow is so we talk about approaches to what to test these are the two main approaches that i see code coverage and case coverage and one is it's kind of like a thinking of like quantitative versus qualitative right so code coverage what that does and it tests it keeps track of how much of your code base is actually executed when you run your tests so for example if you run your tests and only 80 of your code base actually activates or runs or executes or whichever word you want to use to describe it then that means that twenty percent of your code base is not being tested at all and code coverage which essentially uh typically it's a plug you know it's a plugin where you instrument your code and it tracks that and generates reports can give you insight there however that's not the only thing that you want to measure there's also case coverage and what case coverage refers to it typically is test cases which a lot of times mimic user stories so when you think about test cases it describes what the critical paths are and what the different use cases are for your users and your application so for example you could have 100 code coverage of your tests but if there's a certain functionality or an edge case that you're testing that doesn't work from your user perspective it doesn't really matter if you have a hundred percent code coverage if your user can't do what they need to do on your site so like i said we have long user journeys along a critical path so what's a critical path you're probably asking because i asked the same question myself when i first heard this so a critical path you know it's you may also hear it referred to as a happy path but it's what does your user absolutely need to do with your application what is the core functionality so for example if you have an ecommerce site you really want to make sure that they can add an item to a cart and check out right that is what 100 needs to happen if you have a social network or like a blog platform they should be able to write and share a post right if you have a learning platform for example like udemy or something where you're selling courses you want to make sure that whoever comes to your site can search for and then enroll in a course those are some examples of critical paths so if your user goes to your site expecting to be able to do something can they do it and then finally we talk about assertions so what do what types of things do we want to make assertions about because you can assert on everything if you've done um there's like i mean there's all types of things and assertions that you could that you could make so what is the most important for your tests and like how do you decide that so types of assertions that you can make page elements render as expected this is in terms of content so you know is the text on your page correct style is it formatted the correct way is it you know are the is the color scheme working up correctly is it consistent with your design system that you have for your front end application and then also things like visibility and actionability you know can your is it rendering and is it actually showing the right way is there another element covering it if you're in a weird if you're in a different viewport there's some text you know go off to the side and those are the things that cyprus actually checks for you the visibility and the actionability checks when for the certain commands other things that you want to assert on are user actions resulting in expected behavior so if a user like i said goes to your site clicks on a login button does the url after they click on that button is it slash login like it's supposed to be um if you have event listeners on your page are they firing correctly if you hover over something does the expected text appear this or does a tool tip appear where it's supposed to and then finally you want to assert unexpected side effects so going back to um kind of like login profile authentication if you have a user who goes to their user profile page and they update their email address and their profile information and they hit save and there's a modal pops up that says you know profile information saved but the corresponding call to your api to actually update their profile never goes out or it never updates the database then that's a problem so everything may be working on the front end of your application but cyprus allows you to make sure that requests are going out the same way that you expect and you can make assertions on those side effects to ensure that the back end of your application and at least the connection between the front and the back end is working as expected okay and then some additional testing methods that you can employ and there's a little bit more advanced but i wanted to point them out because they're very interesting and very helpful and we do have some guides within cypress for how to incorporate these into your cypress test so one is visual testing so this is actually comparing the visual image of your site using there's a couple of different ways to do it you can use it use it with us with screenshot snapshots or and kind of like an aut of your snapshot so to speak of your site there's api testing so it cypress isn't always the most efficient way to test your api if because it does spin up a browser however if you're going to be spinning up a browser anyway yeah you can you can definitely leverage cyprus for api testing we actually that's what we do in the real world app example they initially started using a different uh framework for api testing when they were developing the app but then found that cypress was helpful in validating the back end before getting to the front end there's also a couple of blog posts here about how you can leverage cyprus for api testing we also have a code coverage guide so as i mentioned earlier if you are interested in getting a more um like quant the quantitative look at what your test is covering your code base we have information and we have a plug-in for that and then also if you're familiar with behavior driven development and you use a framework like cucumber uh you can leverage that with cypress also so there's a link to that as well okay time for their question uh what are the two approaches to evaluating a test suite so again what are the two approaches to evaluating a test suite it's a hint one of them is that more quantitative method one of them is more qualitative so i'll keep an eye out for the answers in the chat okay so let's go ahead and take a look at our test code and walk through it i want to make sure that we had definitely have some time to do this so this is our test file it's our criticalpath.spec.js file so i pull in in our reference types so we have intellisense so that when we hover over for example siteout request it shows the types it tells you exactly what it does and it gives you an example so we have our describe block which essentially describes a suite of tests we're describing it as our just to do mvc here we have our before each hook again this is going to run before each of our tests and what does that before each hook do it resets to-do's and visits the site so we make we're using side-up requests so sign up request allows you to actually just create an http request for any endpoint we have an endpoint already in the back end of our application that resets the database so from within our test code we're actually manipulating our application api in order to reset our database in between each test so we didn't have to create anything special for this right we are we're just leveraging with the functionality already built into our application and because we're running right alongside of our app in a browser we can do that so we're making a post request to our reset endpoint with just some empty to-do's between each test and then we're also visiting societ visit this is again one you'll be very very familiar with this is how you visit your actual application page so like i said the first step is you actually have to go to your page and because we have a base url set in our configuration file our local host 3000 we've already defined that elsewhere all we have to do is put a slash here and that's just going to go to the root directory of our local host 3000. okay looks like we got some answers coming in so alan a-l-l-a-n allen you have won a sticker pack so feel free to send me a dm on twitter that's of creates and i will get that up to you just writing down your names here okay so that's our before each hook and you can see how it's quite powerful otherwise you'd have to and copy and paste or you know type out if you're not like me i always copy paste which is bad but um you know in in each of your it blocks and as we say you know don't repeat yourself right uh you want to keep things dry and so that's why the before each hook is very helpful in this regard so let's go ahead and take out our it.only because we're going to want to run all of our tests but our first test here is it loads the page elements um and there's a few different ways here that we're checking those things the first is we're using a psi dot contains so side dot contains to-do's this is the test that we saw run and fail and pass earlier you can also use a class selector so we're getting our new to-do and it should again i'm using this should assertions but you can use whatever you like uh it should have an html attribute so have act of placeholder and placeholder should show what needs to be done so if we go to our application we can see here that we have an input with the placeholder that says what needs to be done that's what we're testing against and then finally we're using here our custom command so again if we go back to our commands we looked at this earlier we have a custom command that allows us to just pass through us a data selector in this case we're getting show all and we're saying it should not exist so when we start the test we have no to-do's if we have no to-do's and there should be no element that's showing all of the to-do's so that's just confirming that we have no elements on the page when we start our next test again we're thinking about the core functionality of our app you need to be able to add a to-do you need to be able to toggle it complete or incomplete and you need to be able to delete it right so if you have a to-do app like that's your bread and butter that's your critical path you absolutely have to be able to do those things so the first step is adding to do's and again i'm demonstrating a few different ways to do this the first is you can do it manually exactly like how your user would do so you say okay i'm going to go and get my new to do input and i'm going to type make slides for js marathon top enter and it'll step through those commands and it'll type it out and you'll see it typing on the screen and it'll hit enter you'll see the to do added you can see how that would get tedious to type multiple times so in the second example we're leveraging our create to do command and we're just passing through write tests and it's going to automatically take care of the rest of this the other option which i'm very excited to share this which i think is one of the cool the cool things about cypress is that we can actually just use our application state to create a to-do so if for example you didn't we wanted your tests a little bit faster and it didn't really matter to you how you're creating the to-do's like if you don't want them to type it out each and every time then you could have a custom command for example that just in this case we're leveraging our app store and we're dispatching the set to do and then the add to do commands and again these already exist in our application like we didn't have to write anything additional to be able to do this we're tapping right into the code of our app and that's creating a to do called practice so after we've created our three comm our three to-do's we need to assert that they actually are there so we're the simplest way to do this because i care mostly about the text i don't necessarily care about the html is we're just doing three seidoc contains with uh with the test with the two new items that we've added okay so the next test once we've added our to-do's we're going to toggle completion so again we're going ahead and just leveraging our custom command here to create a to do we're confirming that it was created with sitedoc contains we're going and getting the toggle we're sorry we're getting all the elements that have a class of toggle we're going to the first one and then we're checking that box and that check is just you know like checking the box so checking any kind of a input or toggle and then we're confirming that the to do was mark completed so again we're getting that item that we just clicked on and it should have class of completed and again you can just like even if you don't know javascript just reading through this you can get a sense of what's going on and then we have in this case we're leveraging another custom command toggle first to do which we can see here is essentially just repeating the same steps that we just did and then it's asserting that it just no longer has a class of completed but not least deleting the to-do so again we're creating a to-do we're toggling it complete we're using our custom commands we don't have to type them out from scratch we are clicking on the destroy button and then we're confirming that our to-do list has a length of zero meaning that it's been deleted so let's go ahead and run this test now that we have an understanding of what the code it looks like okay so everything passes as expected and again we kind of looked at this earlier we have new to do we expect it to have an attribute placeholder with a value of what needs to be done and then we expect null to not exist that's good be a little concerned if normal did exist and so now we have our ad to do so like so as you can see here our before each hook we're resetting our database clearing out whatever to do is that we have there we're making a new to-do and this is where we're leveraging our app store to uh so you can see instead of typing out so in this case um let me see where you find it make sure to do oh that's right and up here instead of actually typing it out when you can see it runs through it automatically just puts it right into the field we're setting the to do and then it's adding the to do with this dispatch and so we can see that all three exist on our app so we know they've been added next test toggle's complete so we created to do we confirm it exists we get this toggle class it's highlighted there we check it and then we can see that it's marked off and it has a class so completed we go back to the toggle we click on it again and so you can use check or click i use both so you can get see both cases and then now expects it to not have classes completed as expected last but not least deleting the to do so again we've created a to-do we've marked it as checked we click the destroy button and then it's gone so so we have we have a critical path for our to-do application okay so let's go back to our slides last thing i wanted to do is go through a couple more best practices while we have a little bit of time left and so these are all from our documentation we actually have a best practices guide so if you find these interesting definitely recommend reading that guide and getting some more but i i picked these specifically because they're related to end-to-end testing and to cyprus oh sorry about that using my phone as a controller okay so the first one is when you're selecting elements i've mentioned this before the best practice is to use a data attribute you can use data sci or data test but to designate that that's an attribute specifically for getting selectors when you're testing and this allows it also to isolate it from css or js changes so i was asked before why um a class isn't necessarily the best reason because to select something so if you have a redesign of your class a redesign of your site and the class changes then all of a sudden that selector doesn't exist anymore and your test is going to fail but if nobody ever touches that html attribute because there's no need to then that's always going to be consistent in your test cases another best practice is tests should always be able to run independently from one another and still pass so i mentioned that you can have long tests and you can however you don't necessarily want the state of a test to exit to depend on a previous test so for example if we added all of our to do's in our first test and then our second test we marked them to complete but we didn't recreate those to do's then if somebody changes that first test or alters it in any way then that could break our second test so that's why we have that reset before each hook to and then to essentially get a clean slate in between each of our tests and we're and we'd love we can leverage things like our app store or custom commands to reset our state for each test so i also mentioned that cyprus has built in weights and retries so you shouldn't really need in most cases to wait for an arbitrary period of time you do have that option so you can say in the middle of my test you know wait three seconds before moving on uh has the best practice though typically if you are waiting for an arbitrary amount of time it's because you're actually waiting for something to load or something to happen and it's more effective and less flaky to wait for that thing to actually happen than to have to guess how long it will take so for example you can use route aliases so if you're going back to login if you're logging in and you know that there's a request that completes to your backend once they've logged in you can wait for that request and you can essentially mark it in cyprus and say don't move on until we until i in this until this request completes and then now that you know that that's completed then you can make your assertions on the page once you've logged in for example okay all right so we have about five minutes left uh this is uh down to the wire but we're doing good we're kind of we're finishing up here so uh next steps i did mention that we have a lot of guides in our documentation so network request guide highly highly recommend once you're ready to move beyond the like kind of the test that we wrote today now the network request guide goes into what i was just talking about essentially where you can spy on requests going to your back end where you can stub out routes if you want to mock data or mock responses so that's that's been really helpful when you're once you're getting into that section of your testing same thing with the variable and aliases guide those go hand in hand if you have any questions about how to you know for example like store elements for later or if you need to declare any kind of variables to use in your test code and you need to refer to it repeatedly the variable and aliases guide will tell you the best practices for making sure that you're using those correctly in your tests and then finally we have our troubleshooting guide you know if we do run into any problems or um it just goes through how you can leverage our debugging some of our additional troubleshooting methods it also contains we have an error messages guide and we have a mention before we have kind of a lot of robust resources around this speaking of resources i wanted to share this again it's the same side as before so nothing uh nothing new but i just felt like it was important enough to include twice and uh so it is time for another question another chance to grab your sticker pack and i this is probably the last this is actually the last one so uh so the question is what do cyprus action commands like psi dot click automatically check and so if you don't know the actual exact word that's okay but if you can describe it i'll give you bonus i give you points for that like half points but again what do cypress action commands like sign out click automatically check so waiting for for a few answers to come in there but in the meantime i wanted to thank everybody for your time and for your attention today and your participation it's really love doing this really love being able to talk about cyprus and testing in general i'm a strong believer that testing just helps increase your confidence as a developer and helps you just write better code and really be able to provide the solutions that you want for your users so like i said if you have any questions you can reach out to me i am on github at cecilia creates also on twitter at cesilia creates i'm on github as cyprus cecilia specifically for anything cypress related i tend to double dip on my repos so you'll see both i contribute from both from both users and then again our link to our documentation and then the link to the repository that we worked out of today so all the test code that we worked out of today is on this repository a link to these slides is also in that repository so if you would like to click on any of the resources that we shared today you can go to the repository and click on the slides here to see those those are publicly available and um okay okay we're getting some answers actionability nice first question uh first one that's the exact word i was looking for so um nectarios if you could send me a dm i will go ahead and get your stick back so and i do see a couple of quick questions coming on uh yes so absolutely so electron uh is one of one of the browsers that we run in so you can definitely test with the electron browser and then just taking a look and see if anything else i can answer quickly um i think there was one earlier about environment variables that i missed so there's a lot of different ways that you can use environment variables across different tests so it's actually we have an environment variables guide in our documentation so you have multiple options you can either have them in your configuration file you can use cypress.enb to create environment variables in your test file there's a cypress.enb.json file that you could leverage for environment variables you can pass them through when you actually run your tests and you can also use them as a dot a and b when you pass it through using a cli tool there's plugins in order to override environment variables and then you can also set up your test configuration specifically right here in your test code so you can set up an environment variable there too so hopefully oh yeah page object model as a good practice this is a really really really great question so there's nothing in cyprus that prevents you from using page object model if you like it that's awesome definitely definitely use it i will say uh glove i mentioned him before he has this really really great blog post about uh using app actions instead of page objects so i definitely recommend giving that a read if you're looking for other you know other approaches so uh i will also go ahead and i'll include that in the repository i'll add that link to the repository as well okay awesome thank you very very much for all your questions and um and everything's like i said please feel free to reach out to me on on github youtube twitter everything and thanks again for all your participation alright have a great day

Channel: This Dot Media

Views: 2,141

Keywords: JavaScript, Angular, Vue, React, RxJS, React Native, Flutter, Lighthouse, Cypress, Bazel, NgRx, Node, Ember, HTML, CSS, Tailwind, TailwindCSS, web developer, javascript tutorial, programming, architect, This Dot Media, Tracy Lee, Google, AWS, Azure, Microsoft, software engineer, developer, Laravel, NextJS, nuxtjs, women in tech, 100 Days Of Code, VueX, react hooks, GraphQL, react js essentials, angular essentials, vue js essentials, API, modern web, podcast

Id: NHfA9Lm_5i4

Length: 60min 58sec (3658 seconds)

Published: Wed Jul 22 2020