Cypress End-to-End Testing

[Music] Cyprus is an end end testing library that will change your life as a developer I say that because it allows you to speed up the testing process of the user experience and it will help you catch bugs that you didn't even know existed it's super easy to set up and the learning curve is very minimal so if you have an existing app I recommend that you follow along with this episode in your own project to see what I mean first hand if you're new to the channel make sure to LIKE and subscribe and you can find the source code at angular firebase com in case you're not familiar and testing is the process of loading up your web application in the browser and testing things as if it was a real user performing these actions such as clicking buttons filling out forms and things like that so if you're an angular developer you might already know that angular ships with its own and and testing library called protractor so why do we need Cypress the short answer is that Cypress just provides a better developer experience but the longer answer is that protractor was originally developed for angularjs and it just hasn't evolved the way Cypress has first of all Cypress provides a really nice DSL for writing expressive and and tests which we'll see in the code here coming up then it provides this really nice test Runner which is an electron app that will run your app in the browser and then give you time travel debugging capabilities for each spec so for every action that takes place in the app it will save a snapshot of the state as well as an image of the UI so you know how things change before and after some action took place and in my experience writing a really good test suite is much more effective at preventing bugs than using a state management library like redux or something along those lines for this project I'm going to be starting from the firestarter demo app which already has user authentication and a buyer store database feature implemented in it over the next few minutes we'll test that the user can sign up log out log back in create some items in the database and do a few other things in between the first thing we need to do is install it with NPM install Cypress save dev then I'm also installing a library called chance which we'll use to generate random fixtures for our specs I have completely removed protractor from this project and I'm going into the package.json and changing the end-to-end script to say Cypress open now you can run the script from the command line and it will take you through a series of steps to set up Cypress and your project I also highly recommend that you link your github project to it because you can actually record your test and then save them in the cloud recordings are great for your own reference but they're even better if you have clients that want to see the user experience happen step by step when you finish the setup you'll see a few new things in your project Cypress JSON holds your global configuration options then all of your testing code is in the Cypress directory you can set up your specs to run on typescript but I don't see much benefit in doing that because you can pull in the types in just a plain JavaScript file as well you'll notice four different files here fixtures hold default data that you want to reuse throughout your tests then integration is where you write your main specs that's where we'll spend most of the time here you can also write plug-ins that hook into different life cycle events in the testing process one example would be transpiling your code to typescript if you decide to use TS and then you have a support directory where you can write your own custom commands for Cypress or overwrite existing commands we'll do this later in the video at this point I just want to jump into writing our first test because it's really easy to do I have created a file called sample spec j/s in the integration folder then I'll reference the types so we can get really good tooling and autocomplete in our plain JavaScript file and I'll also bring in chance so we can automatically generate email addresses and text and things like that at this point it's important to point out that Cypress uses mocha and chai as its underlying test libraries so you can't really use just or Jasmine as far as I know but this doesn't really matter because you'll mostly be using the Cypress API to write your specs the first step is to describe the test suite which we'll call fire starter and then I'll set a couple global variables here one is for an email address that will be randomly generated for each time this test runs and then another one for the password the state does not get reset between each test so if you want to go back to the home page for example you can set up a before each callback to redirect the user back to the home page which we can do with side visit and the URL before we get started testing anything complex let's just make sure we can find some text within the rendered page kollene cy contains we'll look for that text in the page and that's all you need to write to test that that content is in the page but you can also write more traditional test code where you explicit we declare your subject for example if we expect two to equal two I have very rarely write tests like this in Cyprus but I just want you to know that it's possible so if we look at the spec you can see it first ran R before each callback then it lets us know whether our tests passed or failed and if we hover over that contains it will highlight where it found that text in the page in this particular app I have router guard setup to block certain routes if an unauthenticated user tries to access them in this next spec i'll show you how to navigate around the app and then verify that that particular route gets blocked this app has a drop-down on mobile layouts so we need to make sure the actual link that we want to click is visible on the page before we try to click it with cyprus which in this case means clicking the element that has an ID of nav toggle to do that we can call Cyprus get along with a selector which works very similar to jQuery the get method is very powerful and you'll be using it frequently in Cyprus so once we click that button the page then should contain the words firestorm and then we'll go ahead and click on that link which should normally bring us to the firestore page however it's currently blocked by a router guard so it should show a notification message that that user is not authorized to visit that page in this app I have a notification message component which I can grab and then I'll get the children elements from that component and somewhere inside those Dom elements we should have the text you must be logged in this should method is super powerful in Cyprus you can chain it on to any element that you've grabbed to make assertions about it for the first argument you can chain assertions together then the second argument is optional and is the value that you want to compare what's really nice is that we can chain multiple assertions together by using and for example this text might be contained in the Dom but we also want to make sure that it's visible to the user which we can do by asserting that the notification message should be visible if you uncomment the CY dot paws line of code that I have at the top of the spec it'll allow us to go through each item step by step so with that one line of code we can just click the next button up here at the top and it will take us through each step and show us where the UI is being clicked and what is happening in response when it clicks the button it will navigate to a new URL and then you'll see at asserts that that notification message has the corresponding text so now let's go ahead and sign up a new user and we'll do this with email passwords so we actually have to type into a form the first thing we'll do is click the toggle button and then click the log in link then we'll make sure that that takes the user back to the URL page which we can do with Cypress URL and then a should assertion now a best practice I'd like to point out is that you should generally avoid using IDs or CSS classes to select elements from the Dom that'll make your test brittle because those things are likely to change a better approach is to use a data attribute or the actual component name itself in this case I'm using the name attribute on an input element which is very unlikely to change in most cases then if you remember earlier we set up a global email address so I can simply type that email address into the form with the type operator I'll do the same thing for the password then find the submit button and click it then we can verify that we have this new user and we could even verify things and local storage but for now we'll just make sure that it has the right message in the page and then from there we'll go ahead and log the user out so we can log them back in in the next step when we time travel through the spec you can see that it's actually typing in the randomly generated email address into the form input and then it highlights the submit button with the red dot shows you that it gets clicked and then it navigates back to the new page with the proper message displayed then you'll also see all of the a synchronous xhr requests that firebase is making with the identity toolkit to login the user the next thing I want to do is show you how to extend Cyprus with your own custom method so let's imagine we often need to login the user to do something in our app instead of repeating our test code over and over again I'm going to create a login method that we can reuse throughout our test Suites we will go into the support folder and then in commands and then call Cyprus commands add the second argument is just a function that will run the steps needed to execute this command in most cases you'd probably want to log the user in programmatically but in this case we'll just go ahead and have the user click different UI elements until they're logged into their account so what we've really done is just created a helper method that we can use in our specs to keep them concise and readable so getting back to our main spec now we can log the user in that we just logged out in the previous spec and then do whatever else we need to do with the logged in user the bottom line is it's just a really convenient way to share code throughout your tests there's so much more you can do with Cypress that I'll have to make a whole nother video about more advanced concepts again the API is really well documented and intuitive so I recommend that you give it a try I've been using it for the last few weeks and it's completely changed the way that I do and and testing and angular I'm gonna go ahead and wrap things up there if this video helped you please like and subscribe and if you're ready to start building a serious app consider becoming a pro member at angular firebase com you'll get access to all kinds of exclusive content designed to get your app into production faster thanks for watching and I'll talk to you soon

Channel: Fireship

Views: 171,865

Keywords: angular, angular 2, firebase, webdev, app development, typescript, javascript, lesson, tutorial, cypress, cypress.io, cypress testing, angular cypress, firebase cypress, angular firebase cypress, angular e2e, protractor, cypress.io angular, protractor alternative, cypress typescript

Id: 7N63cMKosIE

Length: 9min 33sec (573 seconds)

Published: Fri Jun 22 2018