Learn Cypress in 3 Hours | Full Cypress Tutorial | Cypress Automation | LambdaTest

welcome to the first video in this series  on using cypress in your web applications   throughout this series we'll have individual  videos that show you how to use cypress's   testing suite to make sure that you provide your  users with the high quality web applications that   they have come to expect in doing so we'll be  partnering with lambda test lambda test is a   cloud platform that lets you run both your manual  and automated tests on your websites and web apps   across a variety of different  browsers and operating systems   so rather than running your tests locally or  relying on another series of servers lambda   test provides you with their cloud platform  to utilize their resources to run your tests   and show you a really cool dashboard of how your  tests are performing if there are any flaky tests   if things are passing if things are failing  what things need to be tightened up and those   sorts of things so throughout this series we'll  be focusing on how to use cypress specifically   and toward the end we'll show you how to integrate  cypress with lambda tests quality cloud platform so getting started my name is chris i'm a  front-end engineer based out of austin texas   i use cypress in my day job and i love it it has  made the testing process so much more smooth and   enjoyable so in this video we're going to make  sure that you've got everything that you need to   get set up with cypress in your application going  from the basic system requirements to actually   installing cypress and running through  the test runner for the very first time   so the goals for this video are to  understand the benefits of cyber   cypress and lambda test to install cypress  in a project to use the terminal based test   runner and the browser-based test  runner so first off what is cypress   throughout this video and through this series  we'll learn that cyprus is a javascript   based test automation framework so you can write  all of your tests in javascript and it'll automate   your tests for you a lot of the syntax of  cyprus should all already be familiar it's   easy to read so that when you read a test that's  written in cyprus it almost looks like english   the lambda test cypress cli or command line   allows you to run cross browser tests with  cypress while using the lambda test cloud platform   of course throughout this series we'll  give more information but feel free to   jump over to the blog or community sections  on lambdatest website for more information so first making sure that we've got  everything to set up and install   cypress you're going to want to make sure that  if you're using mac you've got 10 9 or above   a couple of different options for linux linux  also requires a few extra dependencies which   can be found on the getting started page of  cypress's documentation if you're on windows   just making sure it's windows 7 or above and then  you'll need to make sure that you've got node   installed on your machine as well and cypress  requires node version 12 or above so a couple   of other resources for you at docs.cypress.com  you can find all of the quality documentation   that cyprus offers from a getting started  guide to some more advanced tips and tricks at nodejs.org you can find the latest version of  node and download that if you don't yet have it and then feel free to use the code editor  of your choice i'll be using vs code as it   provides some friendly options and is easy for  me to use but you can use whatever you like so jumping in the only step you've missed at this point is  cloning down a repo called the cypress example   kitchen sink the link is here we'll provide it  in the description so the only thing you'll need   to do is find a folder that you want to store  this uh this project and you'll run git clone   and then paste in the url that you see in the  description from there you'll now have a copy of   this project it's going to include a couple of  extra things that i have removed so that i can   show you how to get get everything set up but your  next step would be to run npm install or simply   run yarn to install all of the dependencies  that have been bundled in with this project from there we're going to install cypress so run npm  install cypress or yarn add cypress either   option is fine depending on your setup now that that's finished installing we can  take a deeper look into the package.json file   here the kitchen sink application comes  bundled with a number of scripts many of   which have to do with specific cypress  commands you'll also want to make sure   that your dependencies array includes cypress it  might be included already in your dev dependencies   object here just making sure that  it has successfully installed   now i mentioned that i removed a couple  of files and folders from this project   you might notice something down in this area  called cypress.json which will automatically   be generated the first time that we run the  browser-based test runner and then you may   also notice a directory up here called cypress  that will also be automatically generated for us   when we run the cypress open command  so i'm going to clear out my terminal   now if you're on your own project and you're  not using this kitchen sink that's totally   fine these steps are still applicable  starting with the npm install cypress step   so the first thing that we're going to do is  run this psi open command which is going to   run cyprus open and this will take us uh well  it'll do a couple of things number one it'll   generate that cypress.json file number two it'll  generate this cypress folder with our series of   tests as well as some other custom commands and  configurations that we'll get into in later videos   and then it will open the browser-based test  runner for us which we'll get into in a second   so from here i'm going to  run npm run psi colon open now you may have noticed that could have taken a  little bit more time than you'd expect if this is   your first time running cyprus locally it might  take a little bit more time since it's generating   a couple of extra files for us and opening up this  little window so here you can see our series of   integration tests you'll also notice that this  cypress folder has been generated for us inside of   here the key directory that we're looking for is  integration which has a series of subdirectories   getting started and advanced examples all  of these files ending in dot spec dot js   are our tests that have been automatically  generated as examples by cyprus so you can   see this describe statement before each  of the tests we're going to visit this url   and then you describe each of  the individual tests in the suite   and do a couple of things which we will get  to how to write in the next couple of videos so if we take a look at this window that popped up   we can actually run our first test  so if we click on to do.spec.js it's going to open up a browser for us  you can see it's opening chrome 91 here   and there is our chrome window opening up so notice all this is happening automatically you can see little flashes of  our application on the right side   and in just over 11 seconds six tests have  run and have passed so what's happening here   is we write our tests in cyprus with the cyprus  open command we actually open up our application   and then we click through it just in the  same way that a real world user would do uh this series of statements will correspond with  the it statements so it displays two to-do items   by default and then you can see our before each  command that was written for us says to visit   the url here and then this is our test body  so this kind of gives us a little breakdown   of what was written and what uh what  happens in our test so we can see we're   looking for this to do list list item we  expected to have a length of two which it does we wanted to grab our first list item we expected  it to have text pay electric bill which you can   see on the right hand side it does and as  i'm hovering over these things you can see   where in the where the ui is in the test so  as the test progresses the ui will change   as if a user was actually interacting  with this which is pretty pretty cool so that was a brief overview of the  browser-based test suite and we'll get it   way more in depth and show you how to  actually write these tests but this is just   a high level overview showing you the the power  and the functionality of cypress's browser based   test runner in addition to  that if we close this out so you can see right here our cypress.json file was generated now  it's just an empty object for now you can add more   configuration which we will do in future videos  but now that this file has been generated for us   we can actually run a different test runner   with this psi run command so cyprus open  was the one that would open up a browser   cypress run is actually going to run it in the  terminal for us so we can do npm run psi run and after a few seconds we can see that it's  getting started we're running our getting   started folder the to do spec and it just runs it  in the terminal i'll try and expand this for us and there we're getting our nice green check  marks showing us that our tests are passing   and this is actually going to run through  all of the tests for us in our terminal so   this getting started spec ran you can see  that this video is being generated for us   and what that'll do is it'll actually make a an  mp4 for us and it shows you the path to that file   so if you wanted say that you had a failing test  and you wanted to watch what was happening in the   browser similar to what we did with cypress open  or that psi open command you could actually go   back and watch the recording of that video to  see the robot user clicking around your site   and you could see specifically what went  wrong oftentimes when i'm writing tests   i'll misspell something i'll have a typo or  something here and there or sometimes a test will   run and it does what it's supposed to do it lets  me know that something broke by watching those   videos sometimes it's more helpful to see what  interaction was happening where the test failed   and how to fix it so now you can see as well we're  running this two advanced examples actions.spec so now you can see we're running this two advanced  examples actions.spec so we're getting into this   second folder of our integration  test and at the end of each spec file   it'll give you this breakdown of how many tests  there were how many were passing and failing   etc how long it took and then it'll make that  nice video for you from here i'm going to go ahead   and pause the video and let the test runner run  through the remainder of the tests and then we'll   pick back up once those are all finished now that  that's all finished running we can see this nice   table with a summary of all of the test files  that we ran the number of tests how many were   passing and failing so some really good insights  into all of our tests and how successful they were   so this was just a high level overview of cyprus  getting us set up running through the test runner   making sure that everything works from here  we'll move forward into writing our own tests   and some more advanced tips and tricks  along the way and again finishing up with   how to utilize the lambda test cloud platform to  run your tests and get some really insightful data   welcome back to video number two in the  cypress testing tutorial video series   in this video we're going to be using the get and  find commands along with a few other little extras   to write our first test and see how to navigate  around the dom using cypress so by the end of   this video you'll have written your first cypress  test you'll understand how to target different   things on the screen using the get command and  we'll also talk about find and within and then   we'll differentiate between this cypress get  and find commands and find use cases for each so we're back here in our kitchen sink application  and and uh it it'll be helpful to take a look at   some of these uh well one of these example files  just to kind of get some structure and see what's   going on so inside we'll open up actions.spec.js  and we can see a couple of things first   uh we we wrap our entire series of  uh tests with this context and it's   just basically a general description of  what's happening in that given test file   so it takes a string as the first argument where  it's just the description and then it takes a   callback function which will then run the rest of  our tests secondly you may notice this before each   before each is a helpful tool that can as the  name implies run certain commands before each   of your tests so rather than writing cy.visit  and in this case this is just visiting a url   rather than writing that at the beginning of each  of your tests over and over cyprus has developed a   way to reuse commands with these before each and  we've got after each as well as another option   so once that's all taken care of now we can write  our individual tests and these are typically   written with this these it statements so similar  to context it'll take in a string which is the   description of like what's going on in the in that  test and then it'll take a callback function which   will then run run your tests so what we can do is  inside of examples i'm going to create a new file   we'll say my first test dot spec dot js i'm actually going to grab this url we  can just visit that same one and this is   actually so if you wanted to run this locally  you could there's a series of start commands   for windows specifically and then if you're  on mac or linux you can run it as well   and that way if you wanted to to run tests and  like update dom elements and text and that kind   of stuff you could you could actually change  the files and then have the cypress runner   pointing at uh your local host but in this case  for this example we're just gonna point to the   live kitchen sync url and this url is the  live version of what you see here in the code so we'll give it some context and we'll say  my first test and then we'll do the callback   function where we actually tell it to do stuff  we'll write a before each where we can visit   uh that link so before each just takes in  this callback function and we can say cy.visit and the url and so now we can actually write our first test  but before we do we want to see kind of what   we're working with so if i grab this url i'll flip  over to the kitchen sync app and this is that url   and so the the nice thing about kitchen sync  is not only does it give you an opportunity to   practice but the actual site uh the actual project  is a bunch of documentation that shows you how   to do a lot of stuff so what we want to do is we  want to say like okay this page should have an h1   element it should exist somewhere on the page and  so we can see one we think that that's probably an   h1 but to be sure we can open up the inspector  and we can see indeed that it is an h1 element   we can see some classes as well somewhere  down here uh there's ids so your your pretty   typical html dom here so if we flip back we're  going to make sure that an actions uh h1 exists so before each we're visiting then  we'll say it has an h1 on the page   so that's the string describing the test and  you can put in whatever you want for that   string just something that's relevant and  then we'll say cy.get h1 that should exist so what's happening here cy is kind  of our like our base cypress uh   like instantiator and then off of that we can  provide a series of chainers chained commands   and so the the base basic one is get so get  is going to find all elements that you uh that   match the given tag or class name or id etc so  in this case if there was more than one h1 which   shouldn't be on a page but if there were  it would actually get all of the h1s on the   page so what we're doing here is we're saying  cy.get so give me an h1 and it should exist now   notice that i'm just passing in h1 if i wanted  to target a class like container for example i would just provide the dot  syntax like you're doing in   if you if you've used jquery this might look  familiar or css when you're when you're writing   your css and then same thing with um with  ids with that hashtag so we're since we're   just targeting the h1 we don't need anything  beforehand we just need the element itself and then we're gonna run you can double  check in the package json for all of these   scripts but we're just gonna be running  cy open so i can do npm run cy colon open so now we've got our test suite here and we don't want to run all of these we just want   to run that individual test file so  we can click on myfirsttest.spec.js and it passes so you can see what's  happening here before it's visiting that link   we're getting in h1 and we sh it should exist   so when you use the get command what it's doing  is it is typically you it's it's using the see   the the cyprus root element and in most cases  that's like the page level so anything on the   page from top to bottom is within the scope of  the get command so it's gonna find any single h1   so we can take this a step further  and we can say it renders the correct   h1 text and let's actually get  this one to fail on purpose so we can say cy.get h1 should and we can say contain text and let's say cyprus if we save that and flip back over we can see that this failed and if  we run it again so the h1 renders but   it expected h1 to contain text cyprus but the  text was actions so the the good news is it's   reading the correct text the bad news in this case  which we knew was going to be bad news is that a   test fails because we told it the wrong string so  let's go ahead and fix that it should contain text   actions save flip back over and  now it does render the correct text   nice so the next thing is uh we talked about kind  of the difference between get and find uh or or   mention that we're going to differentiate between  the two so as i mentioned get is the entire page   but what if we wanted to target something just  within this container well what we could do is we   could actually grab we could use that get command  we could figure out whatever this container is   called if it's a div or if it has a class name  or whatever we could get that and then we could   chain on the find command to then find one single  element within uh within this uh that given class   and so since this is actually a browser we can  just go ahead and open the inspector here so we   can open up the inspect we can narrow this  down a little bit give us some more space so we've got an idea of app that looks like it's over there let's see so  let's right click on actions and then inspect   okay so actions there's our h1 so it looks like  it's a within a class of container and then we   can see a a paragraph tag there as well so what  we can do is we can say like okay um let's start   let's get this container class and then let's  make sure that there's some sort of paragraph   uh text let's just make sure that a paragraph  element exists on this page again not a super   in-depth test but just a way to kind of show how  this find command works so the class is container so we can say it renders a paragraph under the h1 and so now what we'll do is we'll do cy dot get and we'll pass in the the class syntax  with the dot at the beginning so   dot container so now it's going to grab  that container and then we can say find   and we'll just have it look for a paragraph tag  so similar to to get but now we're within that   scope of the container rather than the entire  document and then we can say like should exist okay so we can see they're all  passing we'll run it again so   you can see that we can close the inspector and so what happens here if we click  this renders a paragraph under the   h1 we can see that before each runs we  get the container and then we find that   paragraph tag so this container and actually it  looks like there might be multiple containers because it's highlighting highlighting a number  of elements so let's see so let's scroll down and i'm going to open up the  inspector one more time so on   let's say near the type so we have container  okay so it looks like there are actually several   containers so this test worked because there are  paragraph tags existing in all of the containers   but we wanted just this first this first container  and there's actually a way to do that so we can   flip back over and so i mentioned cy.get will  start at the root level of the page and then   find all elements with this um selector so what we  can do is after the container we can do dot first   and what this will do is we're gonna grab all  the containers and then we're going to grab the   first one and in that first one we're going  to find a paragraph tag and it should exist okay so let's take a look so we got our container  the first one okay so it looks like the first one   is actually this nav bar so let's try and target  the second so you might think like okay let's type   in second but that isn't showing up we could do  last but that's not going to help us because there   are a bunch of elements on the page so what  we can actually do you can do first you can   do last or you can do equals and equals starts  at zero it's a zero indexed helper that will help you target a specific uh a specific element  so if we get all the containers and we want the   second one then we would do equal one so that's  remember zero one this would be the second element and so now it passes and if we take a look  we're getting all the containers now we're   just getting that second one with an index of one  and we're finding a paragraph tag and it exists so that's awesome now let's uh presumably this  if these are all the containers and that's the   first one or the excuse me that's the one  with an index of one which is the second   we can take a look at this next container and we  can show the difference between find and within so within this container here  if we right click on type   you can see there's an h4 we  scroll up so this is a container   there's some actions there's a row um so we  can we can do a couple of different things   so we can say it renders a  section with the correct elements and so what we want to do is we'll  do cy.get container or dot container so we're going to grab all of the containers  then we're going to grab the third one with an   index of two which in this case container one  container two container three index of zero   index of one index of two so that's why we have  equals two so that should give us this container and then we can do dot within now within is  similar to find however you're not just limited   to one like single piece here so notice that i can  get this container i can find the specific one and   then i can find a paragraph tag inside of that  container because the scope has changed however the issue is like let's say i want to find  multiple elements or do multiple things i   couldn't do that with find but within i'm getting  the container that's at index two and then i'm   changing the scope so that i'm no longer targeting  elements all across the screen i'm only targeting   elements within that uh specific container so  now we can do like cy.get h4 that should exist and i can do like same thing i can do like cy.get paragraph that should exist and so now if i flip over you can see  that that passed and i just opened this up   so we're visiting we're getting  the containers all of them   now we're getting it with the index of two and you  can see that it highlighted the one that started   with that type and now within that container we're  getting an h4 and we're getting a paragraph tag   so that's what we want which is uh super helpful  to prevent it from like getting all of the   uh all of the different um  h4s and paragraph tags so   super helpful there uh and super helpful series of  commands to get you started with uh writing tests   so these are pretty simple they're just kind of  like render based tests just to make sure that   things are showing up on the page but we've  seen a couple of different examples so one   before each which is not even targeting  specific elements just like a nice helper method   to save you from retyping the same command we've  seen the get command which is going to start at   the document root level and find all elements  that match your element or your class or your   id we've seen assertions so if they should exist  or they should contain text or things like that we've seen the ability to change the scope  with find so that you get a specific element   and then in that you can find a  single element and do some tests on it   and then additionally we've done the within  command the within um chained command where   you can change the scope and run a series of  tests within a certain element on the page   in the next video what we're going to do  is take a look at installing our first   plugin so the cypress community has a wide  array of plugins that can be helpful for   certain use cases and in this case we're going to  be using a plugin called cypress testing library   which will kind of enhance some of the uh the  default locators that we already get out of   the box with cypress and provide some some  useful functionality for writing more tests   all right so in this video we're going to take  a look at the cypress plug-in ecosystem as well   as take a look at the the cypress.json file  which will allow us to do a little bit more   customization but specifically it'll help us with  setting things uh like environment variables which   will help with some reusability and customization  so the goals for this video are to use your first   cypress plug-in we're going to be using a plug-in  called cypress testing library and by doing that   we'll help you understand the benefits of  leveraging react testing libraries commands   so what cypress testing library does is it  allows us to use the commands like find all   and find by that react testing library offers  and so it'll help to kind of like augment   the get and find commands that we  learned about in the previous video   and then additionally we'll utilize the cypress  json file to create environment variables   specifically here but it'll be kind of our  first taste our first look at that customization   that we can do through the cypress.json file  okay so you can see here in my terminal that the uh we're running a local version of this  so we're not using the live version we're   using localhost 8080 and so if you look in package  json there's a couple of different start scripts   i'm on windows so i use the start ci windows if  you're on mac start should work just fine for you   and then here's our test file remember  it's in our cypress um our cypress folder   inside of the examples directory and so now  that we're caught up kind of where we're at   here it is localhost 8080 running and this is the  same application that you saw live but we've just   got a local version of it running and then here  on cypress's documentation section their website   they've got this plugins directory and inside  they've got all sorts of different plugins   for doing different things that cyprus might not  offer out of the box and so what we're going to   be looking at specifically here and you can see  there's a ton of them is cypress testing library   and so this will allow us to add on to  the like get and find commands that we   saw in the previous video and so if we uh  click into this and uh take a look at the   documentation here we can see the cypress  testing library github page and it's got   all the documentation that we need to get us up  and running but basically the cool thing is that   you're able to now use all of the um react  testing libraries find by and find all by   commands and so if we click on this and go  to this link we'll be able to see in this api   we can do like by test id for example so get by  test id so we would be able to do find by test id   here find all by test id find by title find  all by title placeholder text i think that's   a cool one so find by place holder text find  all so notice that each of these has a find by   and a find all buy so similar to how um well i  guess a difference to point out would be that   uh when we use the get command that just defaulted  to finding any elements that matched on the page   when you're expecting a single element to like  for example have a specific placeholder text   then you can do find by and it'll find that  one however something to look out for is that   if you have multiple this will throw an error  and then that's when you would use find all by   so just some quick examples but we'll dive  into actually using this here in just a second   so let's take a look at the documentation and the  installation section so we're going to grab this   this npm script and then flip over to our terminal i'm going to go ahead and ctrl c out of this  and clear it and then i'm going to paste that in okay so now that that is done i'm going to run clear again package.json just  going to check to make sure that it's in here in our dev dependencies and we can see  testing library cyprus so that's good and then there's a couple of other things  so inside of our cypress support commands   js file we need to add this line so let's  copy it and then let's go to support commands   so in cyprus support commands.js we can now import that that list of commands for  us and now we'll be able to use it so let's just   double check so we imported it and now we can now  we can chain off of that base cy command by doing   cy dot and then any of those find by or find  all by commands that cypress testing library   the plugin offers to us via react testing library   so let's go ahead and take a look at our kitchen  sink app so we have our home page and let's make   sure that it's running again so i'm just going  to up arrow a couple times to the npm run script and now it's running again i'm going to clean some   stuff up here so i'm going  to close out package.json and commands we don't need to open anymore either and so now we're in this index.html file so  notice that all of this is just written in   html and so we've got our our body here and this  is the home page that we were looking for before   so now what we can do is we can find specific  elements say by text so there's a piece of text   here called cypress.io so let's go ahead and write  a simple test to just make sure that that exists   so let's copy this i'm just highlighting it and  copying and then in my first test that's spec.js   we can actually go ahead since we've seen all  these we don't need to run through them a bunch   of times we can comment this out and now beneath  this we can say it correctly renders the cypress website link and then similar uh similarly we  can have our callback function and then we can say cy dot find by text and then  we can have our string cypress.io dot should exist so i'm going to go ahead and  open up a new terminal here   and let's go ahead and run that script  so it'll be npm run psi colon open okay so now that that's open for us  we can go ahead and click on that test okay so this test passed  but there's one thing that i   caught that i'm wondering if you did as well  the url is that live url so one thing that   we forgot to do was update this um uh this url  here so that's one uh use case for uh why we're   going to be looking into the cypress json file  to to help us not have to remember this piece   but we can see now find by text cyprus.io and  that that does exist and if you click on this   you can see printed output to your console if we  inspect this and open up our console we can see   that the find by text command was what was entered  you can see there there was one input specifically   something that that something that satisfied  the argument that was passed into find by text   and uh good information here for sure so one  thing that we can do now that we have this set up   is we can set a base url so that we don't have  to remember which url we need to visit each time   so you'll remember in our test at the  top we have cy.visit this this base url   and so we can do now instead is we can open  up our cypress json so i've got mine open   already but just showing you where it  is in the root directory cypress.json   and now what we can do is inside of this  object we can pass in some arguments   and so the first what we want to do is set our  base url so our base url is going to be where   as the name implies where all of our tests kind of  start off uh start off running so what we can do   is we can set it to that localhost 8080 so let's  go ahead and do http pull slash slash local host 8080 and hit save and so now in the  myfirsttest.spec.js what we can   do is we can do cy.visit and then just a  slash and it looks like i accidentally just   deleted the first apostrophe but let's do a  slash here and now i hit save and now let's   open up that cypress menu again or the the  cypress runner and now if i click on that you can see localhost 8080 is now automatically  navigated to just by visiting this slash   so we can add on to this which is going  to be kind of nice so let's say that we   want to go to like the commands page what  we can do next is we can update our test   so we could do like before each we  could do cyprus.visit slash commands   and so now what this will do is it's going  to visit localhost 8080 commands now here   uh the the issue obviously is that this commands  page doesn't have what we're looking for   but you can see now how just you can append you  can append the different um strings to the end of   your you your base url and then you don't even  have to think about adding localhost 8080 or   your live url you just have  it in your cypress.json file okay so let's go ahead now let's say that  we have some things that are like reusable   so maybe it's like you're logging into  your application and you have a username   and password for like the um the test user that  you're gonna have or maybe you have like um maybe   you're running your front end and then you have  a like a backend server that's running in a in a   like on a separate port and you want to have  that url accessible you can set all these things   as environment variables and then access them   through a like a cypress environment variable  syntax so let's take a look at how we would do   that so inside cyprus.json we have our base url  after that we can do env and now anything inside   of here we can list a key which is how we'll  access it and then a value which is going to   be the value that's returned from that so  let's say like we'll say um sorry navbar   text and in this case we just want to grab it from  this cypress dot io text that we entered before   we'll come back to how we'll update this in  a minute but for now in our cypress json file   let's go ahead and add cypress.io and then that  way if we reference navbar text elsewhere like   let's say for example that we want to at at  each of our pages that has a navbar we want   to make sure that it's rendering correctly and  so what you could do is you could paste that in   that find by text cypress.io just to make sure  that the navbar is appearing correctly and is   rendering the correct text on each page but then  say you change it from cypress.io to cypress.dev   now you have to go through every single test  or every single test file and re-update that   with this method and i know it might seem  kind of trivial but this is an example of   how you can leverage environment variables  to then only have to change it in one spot   rather than going through each each one so what we  can do here is we can make sure that this is saved   and then in the uh in the test file we can create  a variable so we can do this we can do this inside   let's do it at our let's do it above the  context and um oh notice up here too i have   this at typescript no check so uh vs code was  was giving me some issues so i just added a no   check to disable the linter in this file so  um if you're getting some odd red squigglies   then you can go ahead and implement that and  it'll hopefully solve it for you as well so   up here what i'm going to do is i'm going to  say const um nav bar text and i'll do cypress dot env and then i want to take a look at  the cypress json file so navbar text is   what we called it here so what we'll do in here  is we'll do env and then inside of uh quotes   we'll do nav bar text so that it  matches the cypress json key here and so   now we have access to navbar text in this  variable which we can copy and then find by   text we can paste in this variable and so now  we're grabbing we're setting our variable here   we're then grabbing it with this cypress.env  and then referencing it by the key and now   we have it stored in this constant and then we're  passing it into nav bar text here so let's save it   let's flip back over to our cypress test  runner and now we've got the test running again and it's passing again so you can see find by text   cypress.io so it passed in the it  passed in the value as expected but this way again now if we're we're on the home  page but say we wanted to make sure that cyprus io   rendered on the commands page and the utilities  page and the cypress api page by setting it in   the cypress json as an environment variable now  we have that reusable piece of information that   we only have to change once if we end  up changing this piece of our nav bar   so as a quick recap in this video we went over  how to navigate the extensive uh directory of   cypress plugins and how to install our first  one with the cypress testing library plug-in   we also saw how to leverage the cypress json  file to set our base url so that we don't have   to remember to type out the entire thing the every  time as well as setting some environment variables   so that we have access to certain reusable  values that we plan on on using over and   over again so in the next video what we're  going to do is take a look at uh sort of the   foundational aspects of cypress in terms of how  it's built on javascript so cypress is built in   a particular way where things are kind of cued  up and work in a secret nature and so that can   throw some little hiccups in things when you're  writing tests and so we're going to take a look   at the asynchronous nature of cyprus and some  some gotchas to look out for along the way   so let's talk about asynchronous cypress so you  may have heard the term asynchronous before in   programming and basically to give you an analogy  it'd be like doing your laundry so for me when i   do my laundry i put it in and i know that that  machine is going to make a noise when it's done   so you can think about that as like a promise  the machine promises to make a noise to say hey   your laundry's done and so the benefit of that  is that i can put in my laundry and i can go do   other stuff knowing that the machine is going to  tell me that it's done eventually and so promises   in javascript and programming works similarly  in asynchronous programming work similarly where   you might try to fetch some data from an api  and say like okay i want this list of movies   or whatever and so that will return a promise  saying like hey yes you're gonna get this data   at some point like go ahead do your thing go  ahead and continue uh running your program   and and when i'm done fetching your data i'll let  you know so asynchronous programming allows other   things other processes to run while that task  is is being fulfilled and so it can either be   fulfilled or rejected there can be error states  and success states but uh kind of a high level   analogy there so for for cyprus it's important to  understand that cyprus runs asynchronously as well   while also running synchronously so we're  going to go over a couple of examples uh   to better illustrate this point but the goals for  today are to compare synchronous and asynchronous   programming which we kind of just did and then  understand how each plays a role in writing   cypress tests so we'll go over some examples we'll  write some tests and we'll see how cyprus performs   both synchronously and asynchronously okay so  we've got our project pulled up and i've just   got it running here locally on on port 8080 and  we can go ahead into our first test.spec file   and so we've commented out a few things and what  we're going to do is we're going to actually   take a look at this actions page so we can see  that the the url is slash command slash actions   and as a reminder from our last video in  our cypress.json file we set our base url   to localhost 8080. so that'll automatically uh  send us to to that as our kind of our default   so in my first test we can actually go  ahead and comment out this before each and by all means feel free to create a new   test file i'm just going to keep it in here just  to keep it all in one place kind of as notes but   if you want to make a new file feel free  and then we can comment out this last one it   correctly renders the right link  and so let's take a look at the page and we can see up here there is a a text  field with uh placeholder text of email   so we're going to use that plugin that we uh  that we looked at last time that cypress testing   library we're going to find this element by its  placeholder text and we're going to type into it so we can say it types into a an email field and then here we can do cy dot  visit and we can do slash commands   slash actions let me just double check  that url slash command slash actions good we can do cy dot find by placeholder   text and again this is that cypress uh testing  library plugin that we're using here so this is   not us a default cypress command and we  can look for email and then we can type test at email.com and then here to show what's happening with the  synchronous and asynchronous nature of cypress   we're going to add a cy.weight and  we'll wait for 5000 milliseconds or   5 seconds and then up here at the top let's do actually let's put this at the bottom excuse  me we'll do console log test is finished okay so we're going to visit command  actions we're going to find this   this text input by email by its placeholder  text and then we're gonna type something   we're gonna wait five seconds and then  we're gonna see that the console has printed   test is finished so in a separate  terminal we can do npm run psi open and we can run our tests back here okay cool so our test is passing we can see  that it typed in to that text field which is   pretty cool that's something new where we can  tell it to like go do something on the screen   let's take a look at the console so  if we right click and hit inspect   and go to the console we can see test is  finished okay great that's what we expected   so let's clear this out and remember the order  we have the visit find by placeholder wait 5   000 uh or 5000 milliseconds and then console  log so we should see the console log at the end   so we refresh this test is finished but the test  is still running waiting five thousand so test is   finished was printed to the console first even  though it was at the end of the test so this is   an example of how cyprus can run asynchronously  when you're not using cypress commands so if we   take a look at the test console log we can see  here that this is not a cy dot whatever command   so whenever you're writing javascript which you  can do in cyprus one thing to remember is that   whatever that uh that non-cyprus  javascript is that's gonna run first so cyprus will run all of its own commands  its cy dot commands it will run those in order   uh so you can kind of think  of these as like as little   kind of mini promises or or chains of promises  where it's putting all of these in a in a queue   so it'll do a cy dot visit if this succeeds then  it will move on here to this find by placeholder   text if that succeeds then it will type if that  succeeds then it will wait 5000 milliseconds   but this console log since that's not a cypress  command that's just going to run right away so   behind the scenes what's happening is cypress has  this setup where essentially it will put all of   these commands in a queue and so you might think  like well all it's doing is visiting and then   finding but behind the scenes what's happening is  and you can take a look at this where if we if we   look specifically at the find by placeholder text  let's let's mis-type this so let's do like email   and hit save and then if we go back to our test  runner and refresh this you can see this bar here   where it's trying to find  by placeholder text email and so cyprus has a default timeout where  for its actions uh i believe it's yeah four   so four seconds and there are ways of  updating this in that cyprus.json file   it's going to so it visits the commands  actions that one succeeded so that one was fine   and then it was looking for that email text  which doesn't exist so it's gonna try for four   seconds and then if it doesn't find anything  it's going to fail and the test is going to stop   notice that test is finished was still printed  so even though that failed out we can still see   the asynchronous nature of cyprus will  still print out the non-cypress commands   or execute the non-cyprus commands in  this case it printed to the console   but the rest of the cypress  commands will run synchronously   so not only is it fine by placeholder text it's  like all right cyprus like wait until you find   something that has this placeholder text of email  and then if you can't find it then just fail out   but if you can find it then proceed  to the next test so if we run it again if you can find command slash actions great  move on if you can find this placeholder   text email awesome move on to typing if  you can successfully type that which you   should because it's not looking  for anything this is an action that   you're telling it to do rather than like  finding something there then you can wait until we run it one more time  and you can see now it's moving   on each time because it found it immediately so important to understand that when you're  writing tests if you have any sort of custom   javascript if you're trying to execute something  outside of the scope of a cypress command   just keep in mind that that that non-cypress  command is going to run first and so if that   impacts the order in which you're writing your  uh your locators your actions things like that   uh just keeping in mind that those non-cyprus  commands are going to run first and then the   cypress commands are going to run synchronously  they're going to run in order remembering that uh   they own the they run in sequence as uh as each  command succeeds so if the command succeeds it   moves on to the next command if it fails then the  rest of the test fails so now that we understand   at a base level the difference between synchronous  and asynchronous functions in a cypress test in   the next video we'll go ahead and take a look at  ways to execute non-cypress commands in javascript   asynchronously so that you can kind of  control the order in a more predictable way   welcome back to video number five in this  video we're going to build upon what we   learned in the last video about the  synchronous and asynchronous features   of cypress and explicitly look at how to handle  non-cypress async promises so if you remember   any cypress command with the cy dot syntax  anything that's built into cyprus is going   to queue up and then run an order but if we're  using some sort of non-cyprus command in the   last video we looked at console logs but maybe  you're looking at like a network request or want   to do something with some data that's coming  in if it's not a cypress command it's going to   uh run first before any of the cypress commands so  the the learning goal in this video is is pretty   simple we're going to look at when to use the  dot then method in cyprus which is built into   cyprus to explicitly handle non-cyprus promises so  let's go ahead and dive in okay so quick refresher   on our last video we saw that any of these cy  commands are going to run in order they'll run   sequentially sequentially but then this console  log since it's not a cypress specific command it's   going to skip the line and run first and so um one  thing that we can do is if you're trying to um run a console log sequentially you can use this  cy dot log and that'll actually print to the   the little cypress um command uh runner  window or excuse me test runner window   and so you'll be able to see this print in order  um and it's helpful for when you're console   logging you want things to run in order but this  can only be used for console logging but let's   take a quick look at this so if we save this and  then we switch over um again making sure that i've   got um two terminals running one with uh the npm  start command on whichever um whichever operating   system that you're on so i'm using windows i've  got that npm run start windows command going   and then in the second uh in the second terminal  i've got the cy open command running which   which pops this open so if i open up the test and  i inspect the console we can see test is finished   is already printed here we wait the 5 000 seconds  and now we have the cy log cypress log used   so that's helpful but again can only be used  for logging information uh there's there's not   really like you can't go ahead and then like grab  that information and then store it in a variable   or like take a a subsequent action after you have  that information you're just using it for logging   so cyprus does allow you to use the dot then  syntax which will allow you to run a cypress   command and then when that command successfully  executes it can run another command even if it's   a even if it's not a cypress command so let's  take a look at what this looks like so if we   pop back over here what we can do instead of this  console log in this we can get rid of the cy log and then i'm actually going to cop uh cut this  console log actually i'm going to cut the whole   eslint disable piece as well so we're going  to visit we're going to find by placeholder   text and type and then we're going to wait  the 5000 milliseconds like we did before   this time instead of putting the console log  afterwards because we've seen that putting   the console log afterwards does nothing  aside from hit that console log immediately   what we can do is use dot then and this is just  like if you've used then in any other project   it'll operate similarly where you have the  callback function and then inside of it we can run whatever command we want so in this case it's  a console log maybe you're um fetching some data   after this so maybe you make like an axios request  or a fetch request um so we'll visit we'll find my   placeholder text will wait and then we should see  the the test is finished at the end rather than   immediately hitting so let's take a look i'm  going to stop this run it open up my console and so notice now test is finished hits at  the end so running it one more time we can   see that the visit command is hit there's nothing  in the console yet we're waiting 5000 milliseconds   and now the test is finished so again kind of  a a smaller scale use case here with console   logging but if we take a look at the test what  we could do inside of here is you could do   uh you know like i said like a fetch request  and then if you had your you know your api dot com or whatever you know whatever you had  inside of here you could then do something with   that data say you had like a variable up top that  you wanted to store some information in and um use   that further down in your test or uh you wanted  to make sure that a certain element on your page   loaded first and we checked for that element  and then making a network request so it's a   really powerful tool to be able to use this dot  then that allows you to use non-cypress commands   in the synchronous cypress fashion similar to  how it it cues up these these commands so this   is kind of a way of like almost like hijacking the  cypress commands to use for non-cypress commands   and in this case we looked at console logging but  again um the dot then can be used for any sort of   non-cypress asynchronous promise commands that  you're looking to run in your in your test so i went ahead and grabbed an actual  api the spacex api endpoint and let's   take a look at what this might look like  in a in a more sophisticated example so   we can drop this down to like  two seconds just for this case   and uh beneath the console log we can do we're  just going to use the fetch api and so i have this api.spacexdata.com v3 missions  and then we can use our dot then   inside of here since this is a promise so we'll  get our response and then we'll response.json it   and then after that we'll grab the data and  we'll i'm going to grab this eslint disable bit and then console.log the data and let's see about formatting there we go okay and then  this looks like it needs some extra space no console with an e cool all right so we're just using a basic uh  basic fetch here to request some data and then   we're gonna just cut we're to console log  that data but this is just to show you kind   of inside of this dot then now inside of here  we can get rid of this test this finished one   now inside of here we're using a non-cypress   uh asynchronous promise uh where we're fetching  some data and so we can we don't see any cy inside   of here we're just console logging some data down  here after we've fetched it converted the json and uh or converted from json and then and then  console.log that data so let's take a look at what   this looks like so i'm gonna restart the test  console was clear we're waiting two thousand   seconds and now inside of our console we have  our spacex data so the cool thing about that   is then if i wanted to grab like again the  the first um the first item in that array i   could check the mission name and make sure that  it's fetching correctly or i could check that it   um that the array here has a given length  maybe i'm expecting 10 maybe i'm expecting   that it should have some length greater than  zero so really um really cool opportunity to   kind of again hijack that that series of cypress  synchronous commands by using the dot then   this dot then unlocks the ability to then continue  using promises because if we put this fetch on   the outside like we saw in the last video that  would just run first there might be some other   commands that we need to to run first so we might  need to visit a certain page we might need to   type something we might need to click on a button  and we want all those things to run first before   we then you know make our our our fetch here make  our our our get request whatever whatever it may   be so recapping we saw in the previous video that  cyprus is going to run in order but any non-cyprus   commands are going to run first so in this video  we're taking advantage of dot then off of cyprus   commands so remember that there does need to be a  cypress command initially but if we add dot then   we can then utilize non-cypress commands like  fetching data to then run sequentially as we'd   expect so in the next video we're going to  build upon this idea by building out some   more assertions so we'll actually be able to test  that an array should have a certain length that a   text should have a certain value that a button  should exist or should not exist things like   that that'll actually get a little bit more  in depth into writing some some more tests welcome back in this video we're going  to talk about assertions in cyprus   so just ways of checking that things are  appearing the way that they should appear   or behaving the way that they are  expected to behave so the learning goals   for this video are to identify and use common  cypress assertions and then also understanding   when assertions happen by default so uh like we've  seen in in previous topics cypress handles a lot   of things kind of behind the scenes by default  and this is also true with assertions where   some assertions just kind of happen out of the box  based on the action that you're taking so let's go   ahead and dive in before we dive into the actual  code i wanted to point out this assertions page   on cyprus's documentation section of their  website you might see some familiar looking   ways of writing tests from other libraries like  chai all of this stuff is built in to cypress   which is super helpful if you're familiar with  these other testing libraries you'll see the   some familiar looking syntax as well as  a list of common assertions and use cases   for those assertions how to write negative  assertions so lots of really good examples   here and i encourage you to take a look at this  documentation page whenever you get a chance   so diving into our code we have our last test  that we wrote we can go ahead and comment this out   and we are once again going  to use the uh the actions page so we can take a look at this navigation menu  and we can see here that on the actions page   we want the class of active to be applied to this  actions link and presumably the purpose for that   is to show you that you are on the actions page  and maybe it'll be a different color or be bold   or something like that so what we'll do is we'll  grab this drop down menu uh unordered list and   i'm just going to go ahead and copy this and then  we'll grab the third list item and we'll make sure   that it has this active class so let's go ahead  and do that we can say that it shows an active   class for the current pages uh for  the i we can say current page and then we can cy dot visit slash command actions and then we can do dot get that drop down menu  and within that drop down menu we can find   a list item and rather than  finding all of them we'll grab the   the third one which equals an index of 2  and we can say should have dot class active so we're grabbing that drop down menu  unordered list we're finding a list item   with an index of two and we're asserting that  it has a class of active remember i've got this   project running locally i'm i've run the cy open  command and now we can run our test in the window   and it looks like we wrote this incorrectly  so let's take a look drop down menu i forgot   to put the period to indicate that this is a  class so let's go ahead and fix that real quick cool so we visited it we found that that unordered  list with a class of drop down menu we found   our list items that in this case equaled an  index of two and we expected list item dot   active to have class active which it does  we can also write negative assertions so   presumably if we have one list item that shows  the uh the active class on the active page   all of the other links should not have that active  class so let's take a look at how we write that so we can write a another test that says it should  not have an active class on inactive pages so will cy.visit slash command slash actions we will get our drop down menu we'll find the we'll say the first list item   really any other uh list item would be fine  aside from that third one and we'll say dot should not have class of active so now if we flip back over to our test  runner we can restart it should not have   an active class perfect we can also chain on  commands so we can make multiple assertions   so let's take a look at what that would  look like so if we have our cy.get um we can chain on to this so we found our list  item first should and then we can uh we can add on   a dot find and within that we can find our anchor  tag and we can say something like should have attribute href and then it should  have a link and we can take a look command slash querying so this is that first one we want to make  sure that it has command slash querying perfect so we visited we found our drop down menu  we expected it not to have a class of active which   passed and then within that list item  we found the anchor tag that was nested   within the list item and we expected  that anchor tag to have an attribute   of href with the value of command querying which  it did so just taking a look back and let me clean   this up a little bit so i'll drop the dot should  and the dot find and then the other dot should   just to make it a little bit more readable so how  how i wrote this we have our drop down menu we   found the first one and we asserted that this list  item didn't have a class of active which passed   after that passed we chained on a another dot fine  so since we are still referencing this list item   we found the anchor tag within it and we  asserted that it had an attribute of href   which was equal to this commands slash querying  and so that all passed which is great so   some things to keep in mind so we we saw a couple  of ways of of writing assertions um a lot of these   other kind of built-in uh commands in cyprus like  visit or click or type or things like that have   built-in assertions so you don't have to check to  see if something exists for an exam for example   so we had earlier in a previous test we had um  this find by place holder text email dot type at notice that we didn't have to  write an assertion that said   cy.findbyplaceholdertext email.shouldexist.type these types of commands behind the scenes are  going to make sure that these things exist or can   be accessed or are somewhere on the page before  running the the type or the visit or the click   um and so just keeping in mind that uh again  cyprus handles a lot of these things out of the   box for you and takes away some of some of that  extra thinking that you might otherwise have to do   welcome back in this video  we're going to be talking about   writing tests with ui commands so interacting  with the user interface things like clicking   typing checking check boxes all the things that  make cyprus truly magical so in this video the   learning goals are as follows to understand  how to write tests that interact with the   user interface and then to recognize when to use  uh command options so we'll go over a variety of   different commands and then some situations where  you'll want to pass in some options depending on   depending on certain use cases for your tests  so let's go ahead and jump into the code   so i know i said we're going to jump into the  code but as uh as i like to do pointing out the   documentation for this so on cyprus's website  there's not a dedicated like commands link   or page excuse me but their api does have a list  of all of the commands that are available through   cypress and lots of really good examples so like  we're going to go over click as one of our um   one of our examples and we'll we'll do a couple  of different things but this really dives super   deeply into all of the options and arguments and  examples and all that stuff for just click and   they have pages dedicated to each of these  actions so would again um encourage you to   take a look whenever you've got a chance so if we  flip back over to our test i've got cypress open   uh that command running i've also got the the  project running it's it's running locally on   on uh on localhost 8080. we have our most recent  two tests we can go ahead and comment these out   and let's start a new one  so we can say that it links to the actions page correctly and then from here we can cy.visit the home page we can cy dot find all by text and we'll look for actions and then  we're going to find the last one and click it uh the reason we're doing this find all  by text actions is because uh we know our   project and we know that that project has a  top level navigation with drop-down items and   one of those drop-down items one of those  drop-down menu options has an unordered list   that when you click on it it'll  open up the sub navigation   that element uh has there there is a link to  this actions page with this text of actions   that one is hidden and that would actually be  the the first one we'll we'll go over this uh   in the actual example here in a second but that's  the first one and that's top level navigation   the last one is the one that actually shows up in  the body and that's the one that we want to click   so once we find that we can actually test the  url that appears so this presumably should   if we click on it it should link us to  this actions page so we can check the   url by using the cy.url command and then we  should say we can assert that it includes slash actions we could do equals and then the  full url but in this case we assume that the the   prefix of the url the localhost 8080 is going to  exist and we just want to make sure that we're   linking to the the correct the correct route here   so we can go ahead and save this and  pull up our test runner and restart so finding all by text actions we grab the last  one which you can see highlighted here in the body   with actions we click on it and it's kind of  nice they show you that little red dot up there   that's like hey we're clicking on this and  then we went to the new url after the page   loaded we checked our url and expected it to  be command actions so i mentioned here the find   all by text actions and we grab the last one the  other one is actually up here in commands actions   so that's the other actions that's actually  hidden but let's take a look if we had done first   find all by text actions first  click and we switch back over   it's looking it's looking it's looking it's  looking and it couldn't find one this element a an   anchor tag is not visible because it's parent on  our list drop-down menu has css property display   none so basically what's happening here is we  have this um navigation but the ui like thinks   that that link doesn't exist so cyprus is crawling  through our code and it knows like hey there is   actions here but the user wouldn't know that  without clicking on commands so when we click   on commands now you can see this unordered list it  no longer has the um display none property on it   and from there you could you could click on  actions so there's a couple of things we could   do we could try and find you know find by find  all by text commands first click on that and   then find all by text actions click on that  the other option that we could do is pass in   pass in an option to our click command and  so what that would look like is we have find   all by text actions first it is finding the  first one but it can't click on it because   it's technically hidden from from view so  what we can do instead is we can do force true and so force true allows this  action to be taken assuming that that   that uh that cyprus found something in  the um in the ui so if we flip over now oh i put force true in the in  first instead of click my mistake so force inside of click and now that works so we found the first one and   we clicked it so you'll notice that  it's not even showing up in the ui but it it finds the first one and if you were  to uh click on this first and and inspect in   the in the console you can see that there's a  there's two anchor tags that are showing up and   we're grabbing that first one and this is what  it yielded there's one element so um again it's   it's nice of cypress to provide this level of  detail and insight into your different elements   so that's one option there um  and as i mentioned we could have   written a longer test but in this case it's  it's more concise to just do force true   all right so let's do some more uh more ui  commands so we can do it lets you type in an input   field we've seen an example of this before but  let's go over another one so we can do cy.visit slash commands slash actions we'll do cy dot find by placeholder text and again this is only going to work this  find by placeholder text and find all by text   if you have the cypress testing library plugin  installed so if you haven't watched that video   uh go ahead and take a look it's it's  posted and we'll walk you through how to   to set up that specific um that specific plugin  for this project so find by placeholder text   we're looking for one with the placeholder text of  email and then we'll type in there we'll say test   and to assert something we can  chain on dot should have value test so let's refresh this so let's you type in  an input field we went to commands actions   we found by placeholder text email which you  can see highlighted in the top right there   we typed out test and then we expected  it to have the value of test which it did   if you wanted to type in this disabled  text area if you tried to it wouldn't   work initially but you could of course use that  force option that we that we just took a look at all right next it lets you clear an input field so you can manually clear out your input  fields with this clear command so we'll go   ahead and visit that same page we'll copy  this we'll do cy dot find by label text we'll do describe with a  colon we're going to do type test description we'll say it should have a value of test description and we can copy this just  to make sure that we didn't do a typo you can   of course put these in variables if you want  to be extra safe so should have value test   description we'll do a new line and we'll do dot  uh clear and then we'll chain on dot should have value of an empty string so this is all chained together i just put  on a new line for readability so we're going   to find by label text describe we're going  to type into that input test description   and then we're going to check to see  if it has the value of test description   then we're going to use this clear  command so we'll chain that on to the same   the same line and we'll make sure  that it has a value of an empty string so we'll restart this lets  you clear an input field so   we visited commands actions  found describe which is here we typed in test description which you can now  see in the top right when we expected it to   have that value we then cleared it and now you  can see it went from test description up there   to now empty and then we expected it to have  a value of an empty string which it does next let's look at check boxes  so it lets you check a check box so we'll visit our command's actions and then we'll cy.get so this we're going to use just the regular  get and if we look in actions so here's our   check box section we can see that it has a class  of action check boxes and there's an input type   of checkbox so we'll use that information to to  grab the checkbox that we want so we'll cy dot get   dot action check boxes where the type equals checkbox we'll grab the first one and we'll check it and then we'll say that it  should be checked so this is the equivalent of   the have value we we've got it built in  where it should be checked or or not so taking a look at this one that just ran  so let you check a check box we visited   we got the actions check boxes and you can  see all three of those uh check boxes are   are highlighted in the top right then we grab the  first one which you can see highlighted in blue   we checked it so it shows you that that little  uh red dot where it's actually clicking it and   then we expected the input to be checked  which is true so if we did the second one where we the the index equals one so this is our  second item you might notice that it was disabled and so we run into that same issue   so what we can do here is we can  once again pass in that force true and now even though it's disabled we can  click on it and we can expect it to be checked   which you can see here the ui it shows that  it's disabled we still see that it's checked   so those are just a couple of examples of the  ui actions that you can take so clicking typing   checking you can double click you can right click  again cyprus does a wonderful job of showing all   of these examples and their options and different  ways of implementing these commands on their   documentation section so be sure to check that  out when you're writing your own tests in the   next video we'll build even further upon this by  taking a look at some similarities and differences   between cypress and jquery so we'll be able to  leverage uh some jquery like syntax in writing   our writing our tests and accessing different dom  elements so be sure to come back for that video welcome back in this video we're going to be  talking about cypress hooks so uh cypress offers   four useful methods for running things either  before or after individual tests of run or the   groups of tests has uh have run so let's go ahead  and take a look uh at our goals for today so we're   going to be looking at how to uh to understand  how hooks can minimize some boilerplate by just   um writing a repeat repeatable series of  of code snippets and then using the four   common cypress hooks in a test  suite so we'll look at before   which is the hook that runs one time  before all of your tests have started   before each runs before each individual test  so it's going to run however many tests you   have it's going to run that many times whereas  before only runs one time and then that's it   after we'll run one time after all of the tests  are finished up it again will only run once   and then after each similar to before  each is going to run one time after   each individual test so again with the each  however many tests you have in your suite   that before each or after each is going to run  that number of times whereas just before or after   those hooks will only run once and then a quick  note on the order that cyprus runs these hooks   so the order is before will run one time before  any of your tests run any before each hooks will   run before your tests start your tests are going  to run then any after each hooks are going to run   and then finally after is going to run one time  after all of your tests and after the after each   hooks have run so that's a lot of setup  let's go ahead and take a look at what   this looks like in practice okay so  we have our project running locally   and then the cypress open script is also in  a separate terminal so like we've normally   been doing we've got a couple tests here at the  bottom so let's go ahead and comment these out and then we can write our first uh before hook  so let's go ahead and grab this url from a   previous test and if we remember this spacex data  missions endpoint is going to return an array of   10 missions so before any of our tests run we can  just check to make sure that our api is working   and that it's returning a list of 10 missions so  we can see we had a before each before earlier in   the series let's go ahead and get rid of that  for now we'll come back to it and we can say before and this takes a function and we're going to use  something new cy dot request and this is a method that you can use when you're  making a network request like we're doing here   and you can do some things with the data that is  returned so we can do its body and that so now   we have access to the uh response body and we can  just like assert that it should have length of 10. and then in order for this  before hook to actually run   we need to have some tests so we  can do like it visits the home page and we can just do like a cy visit and then we can uncomment this one that says it  has an h1 on the page and so we can just copy this cy.visit and paste it below so now we've got two  tests and we should expect this before hook to run   one time before moving on to these two tests  so let's save that let's open our test runner so let's go ahead and stop it  we can run it again here we go   okay so visits the home page and has an h1 on  the page if we open this up the first test we   can see this before all that does not appear in  the second the second individual test so before   the before hook which is labeled before all here  presumably just to make it a little bit more   clear in the test runner ui saying before all of  the tests run we're going to run this request to   the spacex api we grab its body and then we  asserted that it would have a length of 10   which it did so that passed and then it just  visited the home page and then moved on to the   to the next test that we wrote earlier something  cool just kind of as an aside so not necessarily   related to hooks but if we uh click on  the its body and then open up the console   it prints out the contents of that body  so we can see that it yielded this array   we've got the subject which is an object and  we can see so um basically what this is saying   this subject is the request itself so this  is all of the stuff that you have access to   off of that cy.request method and then here's  what the response of the body actually yielded   which is the array of 10 missions so  that's pretty cool and you can do some   cool stuff with that storing data to variables  testing testing those variables or using those   bits of information for further tests and things  like that but that's just a quick aside about   the cy dot request method so you'll notice  in our test we actually wrote this cy dot   visit the home page um twice but what we can do  instead is we can utilize the before each hook   to get rid of that boilerplate  so we can cy.visit the home page   so we can copy that let's get rid of  this home page uh visit here and let's   see okay so rendering the correct h1 text we can  take a look we should see kitchen sync presumably   that's our h1 so we want to just check and  make sure that kitchen sync is showing up so an h1 exists rendering the correct h1 text  we can just reuse this test from earlier and we   it should contain the text kitchen sync and  so now we don't have to write cy.visit here and in this test as well so before the before  each hook was implemented we would have had to   cy dot visit the home page before writing the  rest of our test but now because of this before   each hook we can actually get rid of the cy.visit  and now we don't have to think about that anymore   so if we save it and we rerun our tests now we  can see that before all was there so we're still   doing the um request uh see what out request  you can see before each we're visiting the home   page and then here's our test body where we're  getting the h1 and just expecting it to exist   and now in the renders the correct h1 text  we can see that before each is also listed   the before all is only listed once so we're  running this cy.visit before each test and then   running our h1 finder to just check that kitchen  sink is the text that's showing up in the h1   so similar to that we can do an  after each and we can just write something like for for this example we can  just see why dot log after each hook is here and we can go ahead and save this rerun our test we can see our before all runs  once our before each hook is here our test body   and then after each we're logging it and we  can see that after each down here as well   and then finally one more  example we can just do our after and we can say cy.log the final after hook runs once and i think i'm getting a linting error just  because of these double quotes okay so saving that   and now if we look in our test runner and open  up both of our tests we can see the before all   runs once before each is visiting our after each  shows up in the first test but we don't have the   after all because we're remember the after all  is going to run after all of our tests are done   so now once again we have our before each we  run our test body we hit our after each hook   and then after all of the tests are done  we see once the final after hook runs once so those are some useful uh useful methods to  use during your test to reduce boilerplate and   to be able to run tasks at different points in  your test suite without explicitly running them   it is recommended by cyprus that you're running  these within your context or describe blocks so   you could write them at the root level outside of  your context or describe statements like up here   but cyprus recommends against doing that because  uh it may have some unintended side effects and uh   may be hard to keep track of um the various hooks  that are running between uh different test suites   so that's it for this video in the next  video we're going to take a look at how   to use a piece of cypress called fixtures  which is going to allow us to kind of mock   up some data and be able to use that  locally in our test suite so that we   can test for we'll have some a consistent  foundation to test against in terms of data in this video we're going to talk about setting  up fixtures and fixtures are a way of setting up   some local data that can be used for a variety  of things in this video we're going to look   at understanding how to set up and import  those fixtures or those bits of hard-coded   data that we can use and then we're going  to actually write a test that uses stub data   or this kind of hard-coded set of fixtures  to kind of mock out a network request so   that we'll have a set of reliable data so let's  go ahead and dive in so we have our test runner   running we've got our application running  locally and we're in our my first test.spec   so first of all whenever you initially make  your cypress like initial setup cyprus bundles   this fixtures folder and inside of it they've  got an example.json file now you can use this   which we're going to in this video you can add  more json files as well and the default path   to finding and accessing these fixtures which  we'll talk about in a minute when we actually   set this up is cypress slash fixtures so  if we look in here this is just a simple   json file with a name email and body and  we're going to be using this in our test   so if we go to my first  test we can comment out our old tests that we're not using currently  and let's go ahead and set this up so we can   start by just making sure that we can pull in  some data so we'll say pulls data from a fixture we can use our normal arrow function syntax and  we can just uh use this cy dot fixture command   so now cyprus knows that we're looking for a  fixture and by doing so we don't have to type in   this like absolute path of like dot dot  source slash you know cyprus or whatever   by default it goes to cypress fixtures and  so now we just need the name of the json file   which is example and you don't even need to  type in json at the end it's smart enough to   know to look in cyber slash fixtures  and then find this example.json file   so we're going to grab that fixture  so now we have access to its data   we're going to chain a dot then and just grab  the data and you can call that whatever you want and let's just log it out so we'll do  cy.log we'll do data so we can see it   and then we'll take a look at the data that we  get back so we save this grab our test runner   and refresh here's our data and we can see  that it's an object if we click on it we   can see i've opened up the console and here's our  data so we've got our body our email and our name   which we can see in our example json file  these match up so already that's pretty cool   uh just knowing that we can have this set  of data in one spot and we don't have to   kind of similar to the the video from earlier in  the series with setting up the cypress json file   with some like variables and things like that  by using these fixtures we can just write our   set of data once and then have access  to it through the cypress.fixture   or the cy.fixture command so  let's take this a little further   we can also so now we have access to this data  we can actually also update it in line so if we   wanted to modify that data for a specific test  we can say like it updates fixture data inline and so what we do here is our cy.fixture command from before  where we're pulling from example then we're going to take our data and then we can say data dot let's say email  equals updated at mail.com and then let's go   ahead and log out our data and we'll say updated  this time and we can say it wants single quotes and let's take a look at our updated data  so if we save this we've got our test runner so the first one pulls data from a fixture we  can see that our email is hello at cypress.io   and our second one with the updated fixture data   we can see that it's updated at mail.com so  not only do you have access to the fixture but   you can modify it for a particular use case for  whatever your your individual test requires so now   going back to the video the topic on uh using  our cypress hooks we can actually load the   this object the test runner this object and  then have access to the data that way as well   so with the cy fixture command we have the  example json file loaded up but what we can do   as well if we grab so we have before each down  here we can we can do it up here and we can do   before each and i'm actually going to write  this incorrectly first just to show you   uh what needs to be done in order to have the  correct access to this object so before each we're going to do cy dot fixture and we'll do we'll grab our example and  we'll do that then and we'll have our data and then we'll do this dot data so we're  taking the this object in the in the test   suite here and we're saying this dot data  equals data so we're just creating this data key   on the this object and then setting  it equal to the data that comes in   and so if we save this and run it  we're actually going to get an error cannot set properties of undefined  setting data so the issue here   is that when you use the fat arrow syntax   uh cyprus the the test runner doesn't have access  to the this object because of the the way that the   scope around this works so instead of writing  a a fat arrow function what we can do instead   is we can use the function  syntax so we can say function data and so now we have access to data and  we can update the this object so we save this   and actually so we want a console log  let's go ahead and uh so we can cy.log this let's take a look at what we've got so before each we have access to the this object and so what  we get is this dot data is actually undefined   so i think we actually need to do instead  is uh not console.log out rcy.log this   why but log this dot data and so now we can  take a look so if we rerun our test suite   we open this up before each now we have this  pointing to an object and now we can see   we have access so this dot data is equal to now  our body email and name so that's another way   of accessing our uh our fixture data and being  able to use it in a test and so now for uh a   a bit of a um an extension or or a more real world  example is we're going to actually look so we're   not cop uh covering this method in this video in  depth specifically but we're going to take a look   at cy.intercept and basically a high level view  of cy.intercept is it's a way of kind of mocking   out or stubbing out data so if you're if your  application makes a network request what cyprus   can do is it can say like hey i'm expecting a get  request to this end point when i i cyprus see this   uh request go out i'm actually not going to make  that request externally but instead i'm going to   like stop that network request from running  and instead use whatever data that um   that i the test writer am providing so let's take  a look at what this looks like uh in practice   so we can say it uses fixture data in a network request and so why you would want to do this uh this is  helpful for making sure that you've you've got   if you're not concerned about testing your api  specifically uh in a in a given scenario so you   obviously you want to test your network requests  uh themselves but if you're just like looking to   make sure that the ui is rendering correctly  or that data some data is being pulled in uh   in the way that it's anticipated um you can do  this and and not have to worry about any sort   of like issues with the back end and you can kind  of test the front end in isolation by using this   fixture data and so what we can do is so we exp  uh it uses the fixture data in a network request   and so now we can use this function  syntax and we can we're going to visit   uh commands slash network requests and this  is just a different page in the application and so from there we're going to intercept and we're going to be looking for any get requests   that are sent to anything pointing  to commands or excuse me comments and so specifically uh the way that this  is written is there's gonna be a network   request to comment slash one with this uh button  that we're about to click through cyprus and   what we're going to do is we're going to provide  it with this dot data so in the before each   we set this dot data equal to our data in the  fixture and we saw that logged where the this the this object had data which is now set  to our fixture data and so what we're doing   here is with cy intercept we're looking for a get  request that's pointing at our comments endpoint   and instead of pulling down the  comment information we're replating it   replacing with this.data so actually let me  back up a step let's go ahead and get rid of   this for now and we'll come back to it just so  you can see what this uh what this looks like so cy dot intercept we're  just gonna uh intercept the   the get request and we can actually  alias this so we can call it get comment and then we're gonna grab a button so  there's a button with a class of network   dash btn and we're going to click on  it and so the way that that button is   designed is it it'll fire off a request to  this comments endpoint then we'll wait for at get comment so this alias that we set up here   can now be accessed with this at sign  and then the the name of the alias and then what we'll do is  we'll look for the response and we'll see why dot log the response and we'll take a look at what we get just  by intercepting this comments request so uses fixture data and network request  actually is not labeled correctly but   that's what we're going to turn  it into so if we open this up   if we take a look at the the cypress log here you  can see that we're visiting that network request   page and then we're clicking on the network  button and you can see here that it actually   logs out this um this comments slash one but what  we're doing here is now we're waiting for that   that uh that get comment and what we're doing now  in this case is just logging the response and so   what we can see here if we look at the response  body we can see that there's some placeholder   text and email and id and a name so what we can do  so this is the actual response but what we can do   is we can we can replace that or we can stub out  that network response with our fixture data so if   we add this this dot data argument now what we're  doing is instead of just grabbing that comments   data from the endpoint we're we're preventing that  data from coming in and instead replacing it with   our data which we set in the before each hook so  if we save this we can take a look now at how that   data has been updated so we open this up  we have our log and now in our response you   can see our body is fixtures are a great  way to mock data for responses to routes so pretty cool and pretty uh pretty functional  way to to provide consistent data for your   test to make sure that again you should be  testing your your api calls and testing your   back end if you have one designed but for the  purposes of testing the front end with cypress   in a lot of cases you do need a consistent  set of data and fixtures are a great way   to as the body says mock data for responses to  routes in our next video we'll go ahead and take   a look at writing some custom commands so if we  wanted to set up you know like kind of a custom   sort of bundle helper function that did something  like this where maybe we passed in a url and a   and an endpoint and a piece of data or things  like that we could kind of bundle this all   together as a custom command and then that way  we wouldn't have to necessarily like rewrite   this particular test each time so custom  commands are a powerful way to kind of make your   your code reusable and uh reduce some boilerplate  so we'll take a look at that in the next video in this video we're going to talk  about writing custom commands in cyprus   so cyprus as we've seen offers a lot of  functionality out of the box but sometimes   you need to add your own custom commands  or even overwrite some of cypress's custom   default commands excuse me so in this video we're  going to learn to differentiate between adding and   overwriting commands and then understand when  to use custom commands versus just using those   existing commands that cypress gives us so  just because you can write a custom command   doesn't mean that you necessarily should you could  potentially over abstract every command in here   and do like a get by id click sort of thing but  you don't need to necessarily break all of your   commands into custom commands so we'll take a  look at when to use these custom commands so   let's go ahead and take a look so as normal we've  got our first test.spec.js file open we've got   our project running locally and we've got our npm  runsi open command run with our test runner open   so when we initially installed cypress as part  of our project it gave us this support directory   inside of our cypress directory and inside of  cypress slash support there is a commands.js file   this is going to be the default place that cyprus  looks for when you're writing custom commands so   when we're writing custom commands we'll go  in here we'll whip up our custom commands and   now we'll have access to them in our other test  files so one common use case for using a custom   command is when you're working with local  or session storage so sometimes as part of   uh authentication process processes you'll  interact with local storage and maybe set tokens   or get tokens or set some other sort of site  information that you that you want to put in   local storage so let's take a look at how to  write a custom command so that you don't have to   rewrite the logic for setting and  getting key value pairs in local storage   so the syntax works like this we have cypress  dot commands dot add so all of our custom   commands that we're adding these are going to be  brand new are going to be cypress.commands.add   we're going to give it a name  so we'll say set local storage and then it takes a callback function now in  this callback function just like a regular   javascript function we can pass in arguments  so we're going to allow this custom command to   accept a key and a value which we will then  use to set our local storage so from here we'll cy.window so we'll get access to the  cypress window then we'll grab that window and we will set the local storage  so window dot local storage dot set item and we'll set it to the  key value pair that is being passed in   while we're in here we'll go ahead and write  our get local storage custom command as well   so that we can then use both in our test.spec.js  file so we'll add another one cyprus.commands.ad get local storage and in this case all we need is a key   because we're not setting anything we just  want to grab that local storage item by its key and similarly we'll grab the window and then with that window we'll grab the local storage dot get item and we'll get the item by the  key that is being passed in so now we have two custom commands   we can access these in our other files by  referencing the name that we gave our custom   commands chained off of the base cy dot so  let's take a look at what this looks like   if we go back over to our myfirsttest.spec.js  file we can comment out some of these older tests and we can say it sets a token in local storage from here we'll do cy dot let me  check the name of the command again   set local storage so i'm just going  to copy this cy dot set local storage   the key that we pass in we'll just call it  token and then the value will say abcd123 so now if we save this we bring over our test runner and we run our test so the test passes let's take a look at  what actually happened so in our test   body we have our window if we click  on this and then open up our console   we can see that it yielded this window  object so if we open this up we scroll down   these are all of the keys off of the window  object we can take a look at local storage   and there we see local storage we have  the key of token and the value of abcd123 so right off the bat we have a reusable way of  setting tokens or setting local storage excuse   me so we have a way of setting a token reusably  we could set other items in local storage as   well like maybe a user id or an email or  whatever we want to put in local storage   so let's take a look at then using that get local storage custom command so  remember get local storage we're going to pass   in a key and then it's going to give us that item  so let's take a look if we copy get local storage we can write a new test that says  it gets a token from local storage we can use that command cy dot get local  storage we're going to get the token   and then from there we can  assert that it should equal a b c d one two three so notice that these  are two strings let's make this a little bit   more clean and set this to a variable  so i'm going to grab this and cut it   and i'm going to set a variable called token and set it equal to that string and then from here we're going to set our  local storage equal to that variable and   we're going to assert that it equals that  variable so this way we avoid any typos or   anything like that we just have the the one  variable token up here so now let's save this let's grab our test runner and run our test one more time so  we refresh expected window to equal   abcd123 so let's take a look at what is  happening here so if we get our window and we see local storage nothing is stored  there so the issue happening here is that   we don't have it in the same test so what  we can do we can say we it sets and gets so let's set the local storage so the local  storage is then being reset on a per test basis   so if we set the local storage and then  we get it we should expect this test to   pass so expected the window to equal  abcd123 so it looks like there's an   issue with how we wrote our get local storage  custom command so let's take a look at that   so the issue here is that we're not returning  in this custom command so if we add a return window.localstorage.get item and hit save  now we can see our tests are passing so   we can see the window the local  storage is set like we did before   we have our window again and this time it  was the get local storage and we can see   once again that the local storage is abcd123  and we expected abcd123 to equal abcd123 so this is a pretty common use case for custom  commands uh that are being added that are not   out of the box with cyprus but what happens if  you want to overwrite a cypress command that   you already have access to out of the box so a  good example that cyprus offers is the ability to   overwrite the type command so that you can  pass in an option to hide sensitive information   in the cypress logs so say for example you  want to test out typing a username and password   and you don't want that password to show up on  your cypress log because maybe you have the video   recording set to true or maybe you're capturing  screenshots and you don't want to accidentally   let that sensitive information out into the  world so let's go ahead and take a look at how   we would overwrite the type command to allow us  to pass in this sensitive option which would then   replace all the characters in the cyprus log with   asterisks so the syntax looks similar it's cypress  dot commands but in this case it's overwrite we're going to overwrite the type command  where we take in the original function   the element that it's referencing  the text and then any options then we can say if there are options and options.sensitive also exists then we can turn off the original log  options.log not equals log equals false   and then we'll create our own log so  in this case we'll do cypress dot log where the element that we're logging  is the element being passed in the name is still type so that's the command  that we're using and then the message what we'll do is we're going to just replace any text  with a star and we'll do this by doing   that's that string dot repeat and we'll grab  the text.length so in this case we still know   that there's text being entered but we're going  to replace any of those characters with a star then from there we'll go to the bottom  and we'll return our original function the element text and options so just adjust this formatting here okay and  now we can save that now we're ready to use it   so we can let's write a new test  and we can say it overwrites the type command by using sensitive characters and we've got another old test that we used  before so we can take a look where we use type so we visited the command's actions and we  found by placeholder text so let's copy this and then uncomment it so we're going to find by placeholder text  email and then we have access to this type   command but since we've overwritten it here  cyprus that commands over it if we pass in   this sensitive option now we should see in  the log that it uh it hides that information   so here and let's actually show both  so i'm going to duplicate this line and in this second example we'll pass in  an options object with sensitive set to and true add our spaces so let's take a look at what this looks  like so if we refresh we have our token   test already passing here in our log though the  first find by placeholder text we can see that   it types out the tests at email.com however with  the second one we overwrote it so that instead   of typing out tests at email.com maybe we want  to hide that information now it's all asterisks so you'll notice here that in the commands  the custom commands that we're doing   are things that can be repeatable across multiple  tests so it saves it cuts down on boilerplate but   it's also something where i'm not going  to just write a custom command one time   for each sort of custom bit of functionality that  i need if i only had one test that i wanted to set   local storage or get local storage i could just  use this command right here one time and be done   with it so this is one of those examples where  should i be writing custom commands for everything   if i'm going to have multiple tests that  utilize this set or get local storage   or if i'm going to have multiple use cases  where i want to hide sensitive information   in that case then yes it's a good a good time  to write a custom command but again if you're   only going to use it once or if you're just  abstracting logic to like click on a button or   maybe chain together a type command by passing in  some text that might not be the best use case so   try and use these commands sparingly but when you  do use them they can certainly be pretty powerful in this video we're going to talk  about using some different mouse events   in cyprus so the goals for this video  are to use the cypress mouse commands and   explore passing in some different options and then  also there might be instances in which you want to   um create a hover effect so maybe  you have some sort of action that   that triggers on hover there's actually not  a specific hover action by default or a hover   command by default out of the box with cypress so  we'll go ahead and take a look at a workaround for   that so let's go ahead and get started so as  we've been doing in these videos we've got our   project running locally and we've got our  our testrunner command uh entered here and   we've got our little test runner ui ready  to go so let's go ahead and write some tests   so we're gonna exclusively use the actions slash  commands page for this so we can actually utilize   this before each like we've looked at before  so we're not going to be worried about fixtures   in this particular video so we can just hit it  with a cy dot visit slash commands slash actions so let's go ahead and take a look at some mouse  events first we can revisit the on click command   so we can say that it triggers a pop over on click so we will uh we don't have to worry  about the cy visit command because   that's being taken care of in our for  before each so we're going to look for our action button class and we're going to click it and then we're going to use our  cypress testing library command   cy.find by text and we're looking  for a specific bit of text in the actions pop over shows okay this pop over shows up on click  so i can i'm gonna go ahead and copy this and then in the test file we'll paste that in and then that should be visible  if i save this run our test and that works and we can see it it clicked  and popped over this pop over shows up on click   cool next we can take a look at some options  that we can pass in so on that same page   there is a little canvas  with an id of action canvas   and from there we can actually tell  cyprus where on the page to click so we can say that it can click  on different sections of a canvas so we're going to grab that action canvas and from there we're going to click on the top oh  this is yelling at me because it's double quotes and we'll do the same thing and we so we can copy this we can paste and we can  do like bottom right and then it'll also accept   um x y coordinates so we can pass in like 80 100. and so if we run that you can actually see these different uh red dots  are where the um the options were being passed in   so you can see bottom right you can see  top and then there was our coordinate there   with the 80 100. and so that you  can see that it's uh 80 in the x   and 100 pixels in the y so  starting from this top left area cool next up we can look at double clicking so it can double click to edit there's  an area on this page that will   activate a little uh like a little edit input  when you double click on it so we'll go ahead   and visit that that same actions command our  command's actions page and then we'll get the class of action div and from there we're going to  use the double click command and when we do this it's actually going to run  a little javascript and hide this action div   so we're going to check that it's not visible and then in so doing   it's going to so it's going to hide the action  div and then it's going to populate the ui with a a class or an input that was previously  hidden with a class of action input hidden and that element should now be visible we can go ahead and comment these two tests  out since we're finished with them and save and we'll rerun this so we can see so we visit our command's actions you can see  here that the action div is in kind of like a   read-only mode and then you can double-click  on it so we get the action div we double-click   on it and now it transforms into that editable  input we're going to do something similar with   this right click where we right click to edit  we can preview what's happening here if we right   click on this just in the ui you can see that  edit so this next test will look pretty similar so we can right click to edit and this one has a slightly different class  on it it has the right click action div it takes the right click command   and similarly after right clicking  on it it should not be visible and similar to the double click this  should now have a right click class   a right click action input  hidden class that is now visible so we can comment out the double click and we'll test out our right click to edit so similarly you can see that that's now  active but if we hover over the different   parts of our tests we get that right click  action div and then we right click on it   and from there you can see the the  dom snapshot if you look down here   before and after so before you click and after you  can see that it's in read-only and then edit mode so the last thing that we're going to  do is take a look at how to simulate a a hover action and so in doing this  we actually want to set up something   in this scripts.js file so if  you look through your directory in app assets js there's a scripts.js  file and we can see a couple of different bits of jquery that have been written to trigger  some different actions we're actually going to   write one that will trigger the um right now  when you are are looking for like if you click on   commands in the navigation bar it'll drop down the  the um drop down menu so you toggle that on and   off with uh clicking but we're gonna set it up so  that when you hover over it then you can see all   the navigation links instead of having to click  on it and this is a pretty common use case in   in uh websites so we can take a look at  that where so we'll just go underneath   this double click and we can write our own  so we can do a little jquery and we can find the drop down toggle and then  we're just going to hover over it and from there we're going to find the list item with the class of active and we're gonna add a class of open so  i i know how to i know to do this just   from a little bit of experimentation with it  there's some other kind of behind-the-scenes   javascript that's built into this project but  after playing with it and it's inspecting the   the elements and everything i  noticed that when you click on   the uh when you click on the navigation it  adds this open class to this uh this this   active class and when it has the open class that  no longer makes the um the unordered list hidden   in the in the dom so essentially this is just  showing that unordered list of of links for   us so now that we have this we can show how to  actually uh hit this hover in our cypress test   so saving the scripts.js file if we go back to the  test file we can comment out our last right click and we can say it shows the nav links on hover and so from here we're going to look for element with a class of drop down toggle and then we're going to use the trigger  command and so trigger can be used to uh   trigger different events in the dom and in this  case we're going to use it for a mouse over then we're going to so this by  hovering over the drop down toggle   this should hit our script to then so  we're hitting this drop-down toggle   we're hovering over and it should add  the open class to our active list item so we're getting the drop down toggle we're  triggering a mouse over and then from there   now that the open class is added we should be  able to see that list of of nav links so we'll get   that on our list which is uh it has a class  of drop down menu and that should be visible so now if we run this we can see so we didn't click on it uh and this  unordered list is now visible so what happened was   we visited we got the drop down toggle which is  this element on commands we triggered a mouse over   which you can see with that little red dot and  the before and after and then we got the drop down   menu on our list which you can see highlighted  there and you expected it to be visible so that's   a workaround knowing that cyprus doesn't have  its own built-in hover command you can use that   trigger command to trigger a variety of dom events  and in this case we used it for the the mouse over in this video we're going to talk about setting  up some github actions so github actions are great   when you're working with the team or just want to  get away from running all of these tests locally   which we've been doing so far in this series the  goals for this video are to understand the purpose   of continuous integration and then to build out  and trigger our first github action workflow so if   you're not familiar with the process of continuous  integration or continuous deployment often   referred to as ci cd continuous integration  is a process where teams of multiple   developers will be able to contribute to  a single code base on a continuous basis   and then continuous deployment is kind of the next  step where we have these contributions and then   we're able to set up some workflows that allow  us to deploy our new updates to that code base   so the benefit of setting up these github actions  is that we have multiple developers on a team   contributing to a single code base and we  can ensure that everything is functioning   as it should by setting up a github action to run  our tests each time that a given event takes place   so in in our case we're going to be setting up  an action to run our cypress tests any time that   somebody pushes a new commit to our code base so  let's go ahead and take a look and see what it's   all about okay so here we have uh my my github  account with the cypress example kitchen sync   project inside of it and you can see that  it's forked from the cypress main account   and so if you go over to the  actions tab you'll probably see   a green button and some text something  along the lines of understanding the   the the consequences or understanding kind of what  you're doing when you're setting up github actions   so it's basically just saying like hey you forked  this project when you're running actions just make   sure that you know what they're doing uh so that  they're set up correctly and you don't mess up   your your project or the upstream project and  so you can go ahead and click that green button   and then you should see um a blank kind of  workflows screen like you see here so from there   we can flip back over to our tests and what i've  done in here is i've cleaned up some of the other   so we had a couple of like other before each  and after hooks and things like that kind of   peppered throughout as we as we uh went through  this series and so those are cleaned up now   and what we want to do is inside of this  dot github slash workflows directory   you probably will see uh you know a series  of like seven or eight different files uh   workflow files i've gone ahead and  deleted those because i don't want   all of them to run every single time if you want  to leave them in that's fine you'll just have   more actions running on your on your actions  tab so i've cleaned that up i've deleted them   inside of this workflows folder i'm going  to create a new file and call it main.yaml so github actions will look inside of this  workflows folder and then any yaml files that   tell github to run that action github  will listen to it and run that action   on your github account so  we'll go ahead and set this up   we can give it a name we can call it cypress  test you can call that whatever you want then we give it a trigger and we'll do this  whenever we push a new change to our project and then we give it a series of jobs notice when  i hit enter vs code knows that i'm in a yaml file   and it takes care of indenting for me that's  important in in these yaml files if you uh if   you're writing your action without attention to uh  indentation then they're not gonna run correctly   so we have our jobs our we're gonna call  it uh cypress run we're gonna tell it   which image to run on and we're going to direct  it to run on the latest version of ubuntu these steps so we can give this a name and  we can say this is going to check it out   check out the project and then it uses the uh the standard checkout action and then from there we are going  to um we're going to use the the cypress maintained github action that  will handle um installing our dependencies   running our project and running our tests for us  all bundled in nicely into this into this action so it uses cypress dash io  slash github dash action at v2   and again this is maintained by cypress and we'll give it a uh let it know what to use as its build command   which is npm run build and we just get  that from our um our package.json file   and then start we can tell it to npm  run start or just npm start in this case so if we give this a save we can add our  new file with a git add dot we can commit   with set up workflow and then we can push and now that it's successfully pushed  github should recognize that change   it should see the new main.yaml file  and then if we go over to that actions   tab we can actually see our test running  remotely so let's flip back over to github and here we can see already set up workflow that  was the name of our commit and uh inside of here   if we uh pop it open we can see cypress run is  happening i'm going to go ahead and pause it here   and then when the tests are finished up we'll go  ahead and take a look at what happened okay so it   took a little over a minute and we can see that  we've got this nice red circle with an x through   it so let's take a look at what happened if we  click inside of sep up workflow we can open up   our cypress run and actually scrolls down to  the error so it says cypress test one failed at the end of this file it  gives us a nice summary of the   number of tests that were run the number  that we're passing and the number that   we're failing so for the most part we did a  pretty good job but we do have one failing test if we scroll up we can see the one failing test  says renders the correct h1 text after four   seconds it expected to see kitchen sink but it  actually saw actions so what that means is that we   wrote a test that was incorrect it was we told  it to expect something that wasn't actually there   but other than that you can see  this nice series of green checks   and then it spits out the error and that's  super easy to fix so if we go back into our test   expected to see kitchen sink  on renders the correct h1 text so kitchen sync and just to double check  it should actually see actions here so instead of kitchen sync we just save that now we can commit that change and i'm going to do git commit am because we  just modified a file and we'll say update h1 test and we'll push that and i'll pause one more time  and we'll take a look at hopefully a series of 100   successful tests now that our tests are finished  running we can see a nice green check mark   so we updated our h1 test and this lets us know  that all of our tests passed and we can confirm   that if we go into our cypress run if we scroll  down to our summary we can see all the green   check marks 21 more passing zero or failing so  pretty cool lots of insights from setting this up   not only does this give you a nice sort of  dashboard indicating the results of your tests   but it also takes away the headache of running  all of these tests locally and then if you're   working on a team this ensures that all of your  tests will continue to pass as new features are   shipped if you're on a team that runs this sort  of continuous integration flow like many teams do welcome back in this final video we're going to go  over all of the different things that you can do   using the lambda test platform to make your tests  more scalable so the goals for this video are to   set up the lambda test cli and config so we'll go  about making sure that you've got the command line   interface set up on your local machine and then  go over the various parts of the configuration   needed to run these tests on lambda test platform  we'll then go ahead and run those tests on lambda   test platform and check out the dashboard  and lots of cool features to see how your   tests are performing and we'll also take a look  at a cool feature that allows you to configure   your tests to run in parallel so if you've got  multiple tests and you don't want them to all run   one after the other after the other and you want  to save yourself at some time there is a way to   configure your test to run uh in parallel rather  than sequentially so let's go ahead and take a   look so before we dive in one small change that i  made you'll notice that there is a file called my   second test.spec.js and all i did was kind of cut  out a couple of tests from uh the test file that   we've been using and pasted them into a second  test file this is for later on in the video when   we go over running tests in parallel we want to  make sure that we have multiple test files to run   so all i did again was just cut and paste a couple  of our tests from our initial file into a second   file so let's go ahead and start the first thing  that we need to do is make sure that we've got   the lambda test cli installed locally on  our machine so we can do npm install dash   g for global lambda test dash cypress dash cli  now that that's finished up we can generate our   lambda test config file so in the command  line we can run lambda test dash cypress init and you can see save that lambda test dash  config.json so we should see that down below   and here it is and so this gives us kind of a just  a a skeleton of of some things that we would need   um first and foremost we do need our lamb to test  username and our lambda test access key so if you   don't yet have a lambda test account be sure to  go and register for one on the lambda test website   so i've got one set up and here is my profile so  you can see my email my username the key piece is   here we need our username and our access token  so i'm going to grab my username and copy it flip back over and paste it in here i'm going to do the same with my access key   so on my profile scrolling down the access  token here i'm going to click on copy and then paste it in and then give that a save so i'm going to go  ahead and leave the rest of this config file as is   so by default it's going to test on chrome  windows 10 version 86 and then firefox windows   10 version 82 and then we can see some kind of  default out of this out of the box run settings   um we're going to come back to this parallels  here right now you'll notice that it's set at 1   meaning that we're just going to run one test at  a time so when we run this on lambda test platform   you're going to see that it runs the first test  and the second test spec files separately when   we learn about running tests in parallel we can  see that those tests can be run at the same time okay so let's go ahead and get that started and in  order to do that we need to make one small change   to our run settings object here so the specs are  currently pointing at dots forward slash star so   any uh like the wildcard kind of any name.spec.js  but our tests are actually inside of cypress   integration here so all we need to do is  add dot slash cypress slash integration hit save and if we flip back over to our  profile we can click on dashboard   and i'm seeing here one parallel session if you  don't see that just go ahead and refresh the page   and now if we go over to view logs we can see myfirsttest.spec.js is  currently running so i'm going to   go ahead and let these tests run and  then we'll take a look at our results so now that our tests have run we're  already seeing the benefit of the   lambda test dashboard so we can take a look  and see that there's an error in our summary   if we go over to the logs you can see cyprus  could not verify that this server is running   localhost 8080. so our cypress.json file still  has a base url of localhost 8080 which worked   fine when we were running our test locally but we  want to point to our production site which is not   at localhost it's at example.cypress.io  so we can go ahead and flip back over and in hours um cypress.json  file instead of localhost 8080   what we can do is replace  this with https colon slash example.cypress.io and now this is  going to be pointing to the live version so i can hit the up arrow let him test cyprus run and now i should see another  test running on our dashboard so this my second test i believe was running from  the first run we should probably see an error here   i'm going to go ahead and pause the video one more   time and we'll come back once  these tests have finished up now that's finished up we've actually got a nice  series of different results that we can take   a look at so you can see here that um we've got  both chrome and firefox uh instances of our tests   uh running which is helpful for uh cross  browser you know making sure that your   your uh application runs and works as expected  across all browsers and we can see from before that in our logs we had the local host issue  so if we move forward then we can see uh the   the length of time that it took um and let's see  if it was this first test nope this one so this   uh this firefox version of myfirsttest.spec.js we  can see that it took three minutes and 20 seconds   and we get this red failed uh x icon and so  this was after we fixed the cypress json issue   and so this is pointing at the production site  like we want and this actually shows us that our   tests ran successfully but there was a failing  test and so lambda test has this really nice   dashboard that gives you really clean clear  information and shows you which tests we're   passing and then you can see here's the one test  that was failing the shows the nav links on hover   and in my first test shows the nav links on hover  we can see that this is the test that failed   and it gives us a reason why it  says timed out we're trying after   four seconds because it expected this element  to be visible so really clear concise easy to uh   pinpoint what the issue was and then in the real  world we'd go back in our test and we would just   fix that and rerun our test to make sure that it  works our second test.spec.js the one where i just   kind of split out the basically the second half of  our test file we can see that it was completed and   we get this nice green check mark and so in our  logs we see some similar information at the top   and then we have our four tests and all four are  passing and then we have our results so four out   of four we're passing um and everything passed  so it's great so uh again the the value of the   lambda test platform is that again everything is  super clear you can see did my test pass which   platforms or which browsers excuse me did my  test run on maybe there's an error in firefox   but not in chrome lots of valuable information  that can be pulled from the lambda test platform   i mentioned that i was going to pause the video  to allow these tests to complete and that pause   for you didn't take a lot of time but for me  took several minutes and the reason for that is   because we have our parallels set at 1. so in this  series of tests each test ran one after the other   and if we look in our automation logs over  here on the left we can see the duration   so what was a second of a pause for you for me  took three minutes 41 seconds plus a minute 23   et cetera et cetera so depending on the  plan that you have on lambda test platform   you can actually run tests in parallel so  rather than waiting to have these tests   run one by one finish one finishing one after  the other we can run all of our tests in parallel   so i'm going to flip back over and  there are actually two ways to do this   so the first way is to go into  our lambdatestconfig.json file   and we can set our parallels here directly so we  can save five so this would be good if you knew   how many tests you wanted to run in parallel every  single time so if you have an application that's   running on a ci cd pipeline and you know that  every single time you want to max out the number   of tests that are run in parallel so that you save  yourself time and potentially money depending on   your costs uh then great then just set that  here every single time and be done with it   the other way is to run it with the parallels  flag in the command line so if you're just doing   a one-off and want to test for whatever reason uh  different amounts of parallel tests then what you   can do is use this same command lambdatest.cypress  run and then you can do dash dash parallels and then the number that you want so dash dash  parallels 5 is the same as putting parallels 5   here so i'm going to go ahead and put it in  the config i'm going to get rid of the flag and i'm going to do lambda test cypress run and  we'll take a look at this running in parallel   now so same little messaging in the console if i  refresh our lambda test platform we can see our 40   tests let's give it one more little click and now  we can see that our tests are running in parallel   so these are running at the same time previously  or if you're following along and you ran these   tests yourself you could see that we'd have one  with a loading spinner and then the other test   not running at all but now that we've got these  two tests running at the same time we're going to   save ourselves a lot of time so i'll once again  pause the video and come back in just a second   okay so we can see that our test results are  the same because we didn't change anything   but they passed and failed more quickly because  they're running in parallel so we took a look   at the automation logs just quickly want to show  the other two tabs here so we have our timeline   and in here we can click on the new data available  we can expand our list and we can see a nice   kind of high level overview of when tests were  run what their statuses were how long they took   we also have this analytics tab that shows us  number of tests run um tests that are passing   and failing and numbers there we can see again  this nice high level overview of tests that are   currently running or completed or failed so lots  of helpful information there again i mentioned the   parallel option being dictated by your  lambda test plan you can check that   if you go to upgrade you can see the uh at slash  billing plans you can see the um the different   plans have different parallel test amounts so if i  wanted to have the live plan and run six parallel   uh tests um you can see that the the price adjusts  accordingly and then the same would go for uh live   web automation and then web plus mobile browser  automation and that's it for the series we've gone   from start to finish writing our first cypress  tests all the way to deploying our cypress test   to the lambda test platform and seeing those tests  run in the cloud so thanks so much for following   along of course if you're still looking to learn  more in the meantime you can check out the blog   at lambdatest.com blog and the community page at  community.lambdatest.com you can also check out   my youtube channel i'm chris da silva thanks  again so much for following along take care you

Channel: LambdaTest

Views: 118,228

Keywords: Cross Browser Testing, Software Testing, Web Development, cypress tutorial, cypress ui commands, cypress hooks, cypress fixtures, cypress, testing, test, cypress testing tutorial, lambdatest, cypress testing, cypress automation testing, cypress tutorial for beginners, learn cypress in 3 hours, cypress full course, cypress full tutorial, cypress in 3 hours, cypress tutorial in 3 hours, cypress testing for beginners, cypress commands, cypress async commands, cypress actions

Id: jX3v3N6oN5M

Length: 182min 17sec (10937 seconds)

Published: Wed Dec 01 2021