React Testing Crash Course

[Music] what's going on guys so a lot of you know that i've been taking it kind of slow on youtube lately just due to some physical issues that i've been having and just because i have some other stuff that i need to get done and i want the content to keep coming so we're going to have a guest video today from a developer named mitchell he actually runs his own youtube channel called tech base of the link to that in the description and he also worked on a react firebase project with me for an upcoming course and what he's going to do today is a react testing crash course which i think is a good addition to the channel because i haven't done much testing content so he's going to get into things like the react testing library jest and some other technologies and just kind of give you an overall idea of why you should test your applications and so on all right so i'll let mitchell take it from here and hopefully you guys enjoy it thank you so much brad for the introduction and hey everyone welcome to this react testing crash course at the end of this video you will have a good understanding of how to test react apps in an efficient and effective way using the most modern testing tools out there so in this video we will go over five things why you should test what to test how to write unit integration and end-to-end tests and for that we're going to use the react testing library and cypress so let's get into it so the goal of testing is to check whether an application behaves as expected the idea is that it will safeguard you against unwanted behavior like bugs when you are changing the code and this could be for example when you are adding new features refactor the code update the app dependencies and so on this will give you a lot of confidence when creating projects for either yourself or your clients because by writing those automated tests you can very quickly check if your app is still working fine without having to manually test the app which is especially for large apps very time consuming so as i said before testing is all about testing the behavior of your application so that's why it's important to have a test priority because testing simply takes time and thus costs money compared to cleaning your car you probably don't have the time to clean every nook and cranny but you rather focus on the windows the outside of the car body and the rims the same goes for testing you probably don't have time to test everything so that's why you need a proper test priority now is there like a golden rule when it comes down to test priority and react no but the following list has worked very well for me and seems to be in line what most people in the testing community would agree on so first we will go through the list and then put it into context by using a real world react demo app high value features are the ones that bring most value or money to an app think about amazon the most important thing right there is to actually be able to view the products and purchase them think about an app like spotify where playing music and also making purchases is probably the most important thing and when it comes down to an app like gmail you probably want that users can simply read and send emails and all those apps often also have other features like changing the profile data or maybe switching from dark to light mode however even those you want those things to work as well they're definitely not the most important features and in those high value features you'll want to focus on the happy pads so just following the correct steps to complete the feature successfully so when testing for the edge cases in your high value features you want to rather focus on the sad paths right so this could for example be if you have an e-commerce shop where you have store-wide rule that you cannot order more than 100 products so you want to test for example what happens if a user tries to add 1 000 items right is he actually able to do that or will we receive an error message something like that the third point is to test for things that can easily break right maybe you've been working on an application and you've just seen that you know over a certain period of time certain features just were breaking every now and then even though you were able to make fixes for them you just feel that it's a sensitive a very easily breakable part in your application and of course it's easy to say well then you should solve it but you know some applications simply do have like these sensitive parts so you also want to write tests for those and then you have what it would call basic react component testing so here you want to focus on the most important ones first so for example the components that are used in your high value features or maybe just ones that are used very often throughout your code base and in those components you will roughly find three things to test user interactions so that could be for example on click or unchange events um conditional rendering which could for example be state changes right so maybe changes in the props or in the use state or in maybe some context you set up or even something like redux and utils and hooks so that could be just simply functions that you use throughout certain components or simply custom hooks you created yourself on the other hand you don't want to waste your time testing so-called implementation details so what a lot of developers did back in the days is that they were testing for example that after a mutation they use state hook the value of the use date hook would for example change the problem there is that it's not a reliable way of testing your react app and is also not resembling how users actually use your application but don't worry too much about it because at the end of this course you have a good idea of how to write proper tests while avoiding these bad testing practices so let's set up the react demo app so you will find a link down below to a github starter repo which you have right here of course you can simply clone this repo by using ssh i'm just going to download it as a zip so there we go and i will copy this folder over to one of my folders right here to keep things organized so now we'll close this up and i'll check if it's in there there we go i will cd into that folder and i will just restart my code editor and now you will see we'll have all the files from the repo now i'd like to ask you to open up your terminal i'll just make sure you can see it as well and i'd like to ask you to run the following command yarn install and and yarn dab and if you don't have yarn install styled you can install it by saying npm install globally yarn but since i have it installed i can just continue i'm saying yarn install and in yarn dev and i'll get back to you once it's installed alright so here it is the demo app uh if it did not work for you you might uh try to just um get out of your terminal like start a new one and run the command yarn dev again that most of the time get rid of most errors what you probably will also notice is that my app looks different than yours because i have an extension called dark reader i have it enabled so that's why it looks like i have dark mode enabled so let's take a quick look to what the app has to offer so first of all i will click on logout and now you can log in with the username john doe and the password is secret but the first e is a three so just copy and paste this click remember me sign in and there we go so well what you see right here this is a banking application and right here you can see payments of friends and yourself of course there's an account page where you can change account details there are some bank accounts you can create you have your notifications and of course you can also make new payments so for a relatively small app like this you can easily you know write a couple of tests and you will pretty much have everything tested but i'd like to show you how we can test this app according to the testing priority list i just showed you and how you could go from there so when it comes down to high value features there are in an app like this two things that stand out to me the first most important thing is that you want to check your account balance and your transactions and you also want to be able to make a payment to someone else obviously there are more important features but in this crash course we're going to focus on those two as being the high value features the second item on the list are testing the edge cases and the high value features so in this app it could for example be to check whether an user is able to submit this form by actually not putting in an amount and a note and thus receiving an error message the third thing on the list are things that are sensitive to break now of course not every application has those and since i'm not aware of any sensitive part in this application and you're probably not as well we'll just skip that one for this course and then we come to react component testing and since this um second part of the form is such an important part of the application and this is actually one component i think it makes it a great use case for testing that as well so we are really close now to writing the actual code but before we do that i'd like to talk about the fact that in this course we're going to focus on the three most common types of tests in automated testing which are unit tests integration tests and end-to-end tests unit testing is about testing a very small part of the code especially in functional programming mostly we refer to testing a function integration testing is testing essentially whether multiple units in your applications are working correctly together so essentially you're combining unit tests into one larger test and last but not least you have end to end test which is all about testing from the one end the front end all the way to the back end so that is really similar to actually mimicking how a user would use your application in the browser but you will find more about that later on especially if you have never heard about these different kind of tests before it doesn't really matter but it might be hard to understand so that's why at the end of this video in the wrap up we will go over this once again and it will be much easier for you to put things into context so what might surprise you is that we're going to write tests from the bottom and up and the reason for that because usually you want to start at the top of the list is that the the test we're going to write at the bottom of the list are more you know they're more concise they're easier to understand so through time we're going to increase the difficulty of every test we're writing so we are going to start by writing two unit tests and we're going to focus on step two of the payment process and for this we're going to use the react testing library which as of today comes with by default with a create react app installation so it's already installed in this repo so let's try to find out how this component is actually called so what i often do is i just um search based on the text i see so right here see please enter a valid amount the error message so we can just copy it go over right here and now you will see that that component is called transaction create step two so we don't really have to worry what's inside this component i'm just going to copy the name of the component and it will create a new file and i will name it just like the component itself but i will say instead of tsx it will say test dot and for this we're just going to use javascript dot js so let's check if by default when we land on this or actually use this component the pay button is disabled so i will say test and right here i will give it a name so i could say on initial render the pay button is disabled and then i'll put in an arrow function and then right here the first thing i have to do is i have to render this component so i will say render and i will import that from testing library react and i will render the transaction create step 2 component as you see it just auto imported the component and what we could do now is we could simply say screen which you also have to import from the react testing library dot debug which is actually a function so now when i save this file and i will just open up a new terminal and right here i'm going to say yarn test just open it up you see that right now the test is going to run it might take a bit of time you'll see that the test now has filled so when we scroll up we can see what actually filled and it says right here on initial render the pay button is disabled so that's the name of our test and then it says type error cannot read property id of undefined and as you can see right here sender id is actually used in that transaction create step two component so when we go to that component um transaction create step two and right here when i scroll up you'll see that the component expects some props including the receiver and the sender so what i can do i can go right here and i can actually pass some props here as well right we're just simply rendering the components so i could say sender is and it could just fake that it gets an idea of uh i don't know just a number and the other one is the other prop is receiver and there you could say that the id is also just a random string and now when i save this i scroll all the way down again you will now see that the test has passed and this is really important to know because if you don't make any assertions in your test which we will do in a couple of minutes from now your test will automatically pass unless there are errors of course so you might wonder what's up with the screen.debug now if we scroll up you will see right here that we have a console log which is essentially console logging the body so this is essentially at the html that react testing library was able to find and right here you can for example see the input element with the amount i'd like to show you another example of how we can show the roles that that are in this document and you will see that this input for example is one of them so instead of saying screen.debug i will now say um get screen dot get by role and just an empty string right here now when i save it and go back to my test you will see we again have a failing test so when i scroll up you'll see right here that unable to find an accessible element with the role empty string but what's nice about this um um well command is that we're able to see what roles are available in this element so you can see we have a heading we have a text box including the amount and the description like the add a note and then we have the buttons and that's exactly what we want to focus on right we want to check whether this button is disabled by default so keep in mind that this button has a name so we can very easily target it in our test so i will remove this and i will put the first assertion right here so we'll say expect screen dot get by role and we want to look for a button and now we want to specifically target that pay button so that's why you saw the name and the um the like the empty gap variable search we just did and we can target it by putting in an object right here and saying that the name should equal pay we're going to do a case insensitive search and then right here we can say to be enabled instead of disabled and i will show you in a minute why so let's save this and run the test now this is a very good use case why you should always do this because of course we wanted to check if the button was disabled but even though we put in is enabled or to be enabled the test still passes and the reason for that and this is something you won't find very often in applications but right here we have some errors and this is related to formic now to get rid of this because i can also show you this actually let's go back right here now you'll see when i click right here on the user you will see that the payment button will be enabled for very just for a fraction of time but you will see as you see right there it goes from like enabled to disabled and that's what's going wrong right here so because this form is using forming that's causing this well i couldn't really call it bug but this behavior we need to use but this is something you usually don't have to use we have to use async and rate right here so we can say async and right here we can put a weight and instead of saying get by roll because right now if you hover over a weight you will see it says has no effect on this type of expression but that's because if we're using async await instead of saying get by row you want to using find by roll so now let's save this and take a look at the outcome of the test all right great so now it says received element is not enabled and that was what we were looking for right and i think it's always a good practice to if you're making an assertion first do it the opposite side right and then um well make it so that the test will pass just to be sure that there are no you know bugs or strange things going on all right so now let's switch it back to instead of being to be enabled to be disabled and now you will see when i will save the file and go back to our test boom and now you will see it has successfully passed so that's great now let's write another test i'm actually going to copy this over here and let's try to test for this button to become for example enabled when we're um putting in an amount and a note right because that is as you can see also a requirement we also have to um put in a node right here so i will change the name of the test i will say if um an amount and node is entered the pay button is enabled or better becomes enabled so in this test we also want to render the transaction create step 2 component with these props but of course we will not need this assertion so i'll just remove it now what i want to do i want to mimic the event where the user is entering an amount and adds a note and then we want to of course do kind of like the same thing but then expect um that the button becomes enabled now before we do that i'd like to um let you know about this like in react with the react testing library there is a recommended testing priority and this is with regard to the queries you're doing so as you can see right here get by role that is for most queries the recommended way to go however if you're going to target form elements which th this definitely is your first um well your you know your preference should be that you try to target that by label text but unfortunately this form doesn't use labels for its inputs right it's just using a placeholder and i can show this to you so i can do screen dot get by row and we do the empty string thing again so now when i scroll up you will see right here that we have a text box but we do not have a name so we cannot target it by saying get by role and well as you can see it also does not have a label so what we then can do since it has used as a placeholder we can use the following query we will be using get by placeholder text so to mimic this user event we can make use of user event that also comes with react testing library so also user event and i have to manually import it so just to copy this line i'll say user event and this is not coming from tyson library react with testing library user event there we go so right here we want to type so we'll say type and then we want to target screen dot get by placeholder text and then we want to um target it by the name so right here it placed all the text was amount right so we can put amount in here and then the second argument is the actual string that will be typed so we can do 50 and i can copy this and we also want to add a note so i can say this should target the add a note and it will pass dinner and now let's do a screen dot um get my row again get by roll there we go empty string so you could also use something like screen.debug but i just um like the get by roll with the empty string because it shows you um well in a better structured way the elements you could say so let's wait for this to run there we go so now when i scroll up you will see that right here we have that input but you will see that right now it has a value of dinner and when i scroll up a little more you'll see that our input field now has a value of dollar sign 50 so the dollar sign of course is added by the code obviously so this is great so now we can simply copy this line and replace it by the screen dot get by roll and well we can do the same thing again so we can first check if it's disabled and of course that should not be the case because we now have properly been um putting in some data into the form and this pattern which you see right here is often referred to as the arrange act assert pattern so in the first phase of the test you are arranging arranging things for example rendering the component then you have your act so it could be you know user events typing clicking things like that and then you have your assertions where you're going to well make your assertions so as you can see right here we got the test result and it says received element um is not disabled which is great because it should actually be enabled so of course you can already guess what happens if we we'll put this in there and save the file boom and there we go we have two passing tests and as you can see testing it's not all that difficult right if you have your test priority in place it's more about translating user interactions in code and making the right assertions so to quickly recap right now you learned how to test for user interactions and how to check conditional rendering because these buttons um or at least right now we tested one button of course but that's essentially you know conditional rendering taking place simply whether a button is disabled or not so next up we have integration tests and as i said before integration tests are about testing multiple units of code which usually results in like one larger test and you will often find that these type of tests have multiple assertions in them right so you often see that you know you have your your arranged so you have your rendering of your component and then you could for example have user typing something you um make an assertion and then the user clicks on something again you again make a new assertion so that's uh most often how this test looks like because you're well like i said before you are testing multiple units of code together so it's good to know that not everyone in the community completely agrees on what actually a unit versus an integration test is right so now you got to keep that in mind that you might come across people that have different thoughts or ideas about that in the end of the video we will wrap things up and we'll talk a little bit more about that but let's actually write our first integration test so when writing tests it's a very good idea to think about realistic user flows and now looking back at our unit tests you know this is not really how a user would use our application right if they would land on this page because you know these are essentially very small parts of that specific user flow but when a user comes here what probably will happen is you know they search for a user and first they look they see ah the pay button is disabled so i will add some data right here now it becomes enabled there we go and it will click on the pay button right that's the most common scenario how users will use this feature so we can very simply combine these two unit tests into one integration test and i can show you how it's very simple i will take this line right here i will put it in this test i'll remove this test from here and well i can leave the the name of the test just like this and now when i will save this you will see that the test because right now we will only have one will pass and of course this is a very simple example but i've often found myself being able to combine you know eight or you know even more unit tests into one integration test and especially in this scenario i would personally prefer it because it better resembles how a user would use our application please keep in mind that integration testing definitely is not about combining unit tests into one test however if you find that you are able to combine unit tests into one integration test right so that it will resemble a more realistic user flow i definitely would recommend you to do it and from a practical point of view you will often find that just a few unit tests are you know much better than you know having like hundreds of very small and concise unit tests now let's move on to writing end-to-end tests which are by far my most favorite type of test simply for the fact that they are so effective in testing you know the things that really matter your high value features and it's also really fun to write them because you can actually see the simulations happening on the screen which you know it's so blazingly fast like no human could interact with an application that fast for this we're going to use a tool called cypress however since it does not come by default with create react tab we need to set some things up so we want to install cypress and in order to do that we can say yarn oops yarn add and this will this will be a daf dependency and we can say cypress and we also want to have testing library slash cypress so i go back to you once it's done all right great so now we can run the command yarn run cypress open and this will now open up cyprus so then you will probably see this thing popping up and as you can see it already has added some tests by default so what i want to do because i want to remove them is i will go right here to the cypress folder and then right here under integration you will see that there are two folders with tests but i will just remove those two folders just like that next up we want to add the react testing library cyprus commands however this is completely optional but i like it because we can then use the same commands we used in the previous test in our cypress test which by default is not supported so i will go to support commands.js and right here i will add the following line we'll say import add testing library cypress slash add commands i'll save that file so let's close up all these files and now we'll go to the cypress folder right here and under integration i will create a new file i will call it payment underscore spec.js and we can start writing a test by saying describe and i'll give it a name i'll just call payment and we have our arrow function and now right here we can um write uh the well the actual test itself so we can say it so that's you know instead of test we will say it just like we did with the react testing library and then i will say user can make payment um and we have our oops we have our error function right here so the first thing i generally like to do is to plan the test right so what are we actually going to do so um well we're going to go through that payment flow but the first thing a user should do is log in obviously right so the first step will be the login and then well let's do that actually john doe secret okay and then well the user probably before um here she's going to make a payment is going to check the account balance right so let's say check account balance so next up we will then click or the user will click on the pay button all right so click on pay button and then we'll look for a user so for example type and click so search or user and then well the user will enter an amount and add a node so add amount and node and click pay then the user is probably going to check we're going to return to the transactions so click or actually return to transactions and then well the user could for example go to the to the like the personal tab so go to the personal payments then it's going for example clicks on the payment so click on payment and then the user is likely going to verify um whether the correct payment was made right so verify if payment was made and the user will probably also check the account balance to check if the right amount has been deducted so verify if payment amount was deducted what i can highly recommend you is to install the following chrome extension which is called testing playground it's made by someone that's very actively like an active maintainer in the react testing library community and what this tool allows you to do is it allows you to hover over elements on your on the page and suggest a query um which is really great again it's optional but i'm going to use it and i recommend you to use it as well but i already have it installed so now if you would open up your cypress window again you will see that right here you see we have the payment in this course back.js file and you can click right here on run one integration spec now it's important um at least i'm going to use the electron environment but you can also test this in like a chrome or edge environment depending on which device you're using but i will just click right here and now you see that right here we have the describe with the the name of the test and it says no commands were issued in this test which is right so that's what we're going to take care of right now so first of all we want to log in and the first thing we want to do is we want to make sure that the user well visits our app so we can say cyprus. and the user will simply visit the root of our site so now you'll see when i save the file the test will automatically run and there you will see whatever localhost 3000 seems to take a bit of time to uh to actually load up but there we have it there we have our app awesome so now we want to actually do the same thing as we did with the react testing library so we want to make sure that user types and maybe also hits that checkbox and clicks on sign in so let's actually and that's why we installed the at least i hope you installed the testing playground plug-in so i'll just open that up so now you'll see when i will click right here on this icon select element and now when i hover over this element you will see it gives me a suggested query it's the get by row text box name username which is great so i will copy this and i will paste it now instead of saying screen because we're using cypress right now we just want to use the cyprus command and instead of saying get by role in cyprus everything will always be fined by role okay or find by you know could also be labeled text or find by um placeholder text but it you can never target something by using get you always have to use find so the next thing we want to do right here is we well right now we target that text box and then we want to say dot type and it will enter should enter right there john doe so now when i save it and i go back to cyprus you will see it's actually going to execute this so let's take care of all the other steps so next up we have this field right here and you see for some reason this one does has have a label text um suggested query and that's simply because um the password input field has well a label to it and the username doesn't right so it doesn't really matter if you can't target by label tag you should prefer that so we'll say cyprus find by label text and then we will type the password which will be secret and then the user probably is going to check that remember me checkbox as well so we'll grab this thing right here copy so right here we have cypress find by roll and then right here we can use check so i was going to check that box and then we want to click that button right here um let's actually i think it's not able to find it right now oops made a typo right there now it is enabled there we go so get my role button awesome and then we can say it should click that so of course this should also be cypress find barrel let's save it and go back to cyprus and take a look what happens boom there we go we're locked in and this is what i really like about you know end to end test tests it's super fast and it's essentially like like well doing manual testing like you know real browser testing but then in an automated way which is extremely extremely valuable so now the next step is to check the account balance now what you will see now when i will log in and use the testing playground tool now when i hover right here over the um the account balance you will see it it gives us a get by row heading with the name of the well actually the the account balance but of course the account balance is dynamic it can change from time to time so this is not a good query and unfortunately as you can see right here it's not giving us any other details as well but cyprus also has this um well tool built in you could say and you can use it by going right here to saying open selector playground and now i can select the um the amount and you will see that it has a data test id and i can actually copy this and i can look for it in our code base um actually let's take a look let's just do this i nav user balance and you will see that this lives in the nav drawer and what you see is that they attached a data test id to um this element right here and i have to say like using a test id is something you should use as a last resort or last resort but in well especially in these kind of cases where the content can be dynamic it's a very good way to target a specific element and the reason i'm saying that and why we are using the react testing library commands with cypress uh is that you know the more your tests are well acting as how a user would use your app the better and a user will never go off by a test id right and that's why we have right here um we have to find barrow and find the label text because that's actually how a user will look at our and interact with our application but especially in cases like this where you for example have like dynamic content a data test id is perfectly fine to use so i'll just close this up and the first thing i will do i will assign a new variable and i will call it let's see current balance or let's actually do old balance because later on we will also use the current balance so i think it might be a little bit more clear to say that we first have the old balance and then grab the nil balance so now we want to store that value um of course so what we can do is i would just copy this to my clipboard and i'll say that then and we will um call this balance for example so also balance and then it's going to return the it's going to set the old balance to the um balance dot text and now let's check what the um well value of all balance is so i can say dot then then we take the uh the uh i don't know balance and return console log console.log balance there we go and you can also open up your console right here so now you'll see the test is going to run and there we go the current balance is now console logged but of course we don't need that for now so i will just remove that part and save it like that so next up we have click on pay button but now we see it's actually new so let's change that and we can go back to our app right here see if our testing playground has a suggested query and it does get a raw button name new awesome copy that cypress find barrow button and we want to click it so we then want to search for a user so well for example let's say user instead of immediately clicking on a user also types so we can do dev and backer right so i'll grab this got a real text box so you know on this page the there's only one text box so this query is uh is is fine to me oops cyprus fiber dot type and we're going to look for devon backer and then let's see it's going to click on well let's do it actually devon becker you can see we only have one result so then well the user's probably going to click on that name so we can say get by text devon backer which is by the way query we haven't used before but if the user is going to click on a certain piece of text and not necessarily a button you can use this query find and say dot click so now let's run this test and see how it goes awesome that works so now let's move on to step two of the payment process so click right here and then you want to target this right here and now you see and also testing playground that extension is not always perfect because well you and i know that in the previous test we we created we were actually able to target these by get by placeholder text but it seems that testing playground is not able to find a suggested query so that's why we uh we we just have to type it ourselves right now so we have cypress find by what was it again find by place holder text and we want to look for amount and then we want to type and i recommend you in in these kind of tests um you often want to work with like a test database so you're not really you know making real transactions in this case um but also try to keep if you're sending amounts or you know these kind of things especially in your happy paths try to keep keep those values low so you don't run into problems where you then have to reset the account balance or something like that right so i will copy this and we also want to get the add a note we're going to uh so now to make sure that we have like a unique note because because if it will add dinner right here then if a user would go to uh their personal transactions right here you will get like dinner everywhere right so we want to prevent that from happening so what i can do is i can make sure we get like a unique node so i'll say const v4 at oops that's the wrong import statement so if you use uuid v4 is required uuid which is already installed into this project and then we can use uuidv4 to create create like a well not necessarily random but a unique identifier okay so the const note is uuid v4 so now i can grab that node and instead of saying dinner put it in here and now when i save this and i go back to cypress you will see that it's going to add that note yep so there you go there we have our unique id the next thing the user will do is of course click on that pay button so let's actually um see if we can get a suggested query for that as well so i will copy this cyprus find my role dot click and that should bring us to the next page and then the user should click on or in this case we we decided that the user will click on return to transactions so you're gonna have a suggested query dot click cyprus by barrel so next up the user will go to their personal payment so of course they've clicked right here and then we'll click on this i'm not sure if it's a button let's see get the roll tap okay copy that dot click find by row and then we'll have the click on payment so of course then the user for example could click on the um on the text of their the note they added to the um to the actual payment so we could do a get by text query but of course in this case we're not going to grab this but we're going to grab the note we created cyprus find by text dot click and well let's actually run this test see if everything is still working now as you can see we have an error so let's take a look it says timeout retrying after four seconds cyprus.click fill because this element is being covered by another element and as you can see indeed that element right here our last transaction is covered by the um by the header and that's why it's not working so i'm not too much concerned about this because some something you could do for example is uh scroll this element into view so um there's this thing called scroll into view which um could also work but not in this case because it takes some time for the page to load and cyprus like by default is trying to it's constantly looking for the element you're trying to target and as soon as it finds it it's going to click or type or you know execute whatever you asked cyprus to do and because you know this is not really working properly because when i go right here to the um let's take a look right here try to click and as you can see the list did not completely load yet proper i think at least i think that's the the cause of this and that's why um you have like a sort of layout shift in the page now i'm personally not too much concerned about this right so of course usually you want to test how a real user would use your application but i can show you that if we would use this in the browser right here so let's make a new a new payment uh caller peaches and click on pay return to transactions and then when i now click on mine you will see i will just perfectly see it so i'm not too concerned about scrolling into the view so i will just force cypress to click on the element even though it's kind of like hidden below another element and we can do that by using force true and as you can see right now it works so right here we probably want to check for two things we want to check if the right node is on this page and the right payment amount so what we can do is instead of saying that we type 5 we can actually make a variable out of this it's of course not necessary but i like it because we can then reuse it so i will say const payment amount is string 5.00 and then instead of doing like a hard-coded string we're going to pass the variable to it and right here verify if the payment was made we can go back to um the real browser so to speak and let's take a look if um it's uh the testing playground is able to help us out so we get a query get by text so say cyprus dot get by text but right here i want to check if like the and we can use string interpolation for that if the minus dollar sign and then we want to have the payment amount right so payment amount and then we want to check if this is actually visible so on the page so we can say should and this is different compared to the react testing library right the way we make assertions but in order to check for this we can check for this to be visible and we can do the same thing for the um for the note right so oops copy this and then right here we just want to check for the note should be visible perfect let's save it and take a look at the outcome yep and i made a typo right there because of course this instead of get should be fined so let's save it and now you can see in the bottom left corner that we have made two successful assertions so now the last step is to check whether the account balance or actually the payment amount has been deducted from the account balance so that's probably the most difficult one because um the string we stored like the where is it the old balance right here this is actually the string including the the dollar and the comma so we have to replace that by a regex so we can essentially target the same element so i will grab this thing right here copy it right so we want to take the balance but then instead of doing this we are going to create new variables so let's say const converted old balance and this is going to be the old balance dot replace and right here we want to replace the dollar sign and we want to replace the comma and we want to do that globally by an empty string and we also want to grab that new balance so this will be converted converted new balance and then we will grab the balance right so what we get passed from the element we targeted and then we have to first convert that to text that's really important otherwise it won't work and now i'm thinking about this we need to actually parse float this stuff right here so say parse float and do the same for the one right here perfect so now we want to check whether the difference between the new and old balance is equal to the payment amount so we can make a custom assertion so we can say expect converted new balance minus the converted old balance or actually i have to swap that around of course there we go two equal and then we take parts float the payment amount okay that should be it let's save it and take a look what cyprus has to say yep there we have it another typo invalid chai property to be did you mean two of course i needed to have two right here and not to be let's try it again yes there we go three successful assertions expected five to equal five and of course if you remember our payment amount was five so there you have it your first end-to-end test and i have to tell you that this is you know quite a quite a large end-to-end test but you see there's a lot of repetition going on right so you have a lot of times you just have to target elements type something clicking but that's you know that's simply how users would use um well applications and websites in general so yeah let's wrap things up and i think this is the most important part of the video because now we're going to put things into context first of all always remember why we write tests we want to check if our app behaves as expected testing simply costs time and for companies it costs money so make sure you have a you know some priorities in your testing strategy so you can get most bang for your buck my testing priority list i showed you before is an example of that right and it just gives you some guidance in your testing workflow very often you will find that your high value features are best to be tested with at least some end-to-end tests using tools like cypress for most of the other things you usually can simply use integration or unit tests to test them as well but keep in mind what i said before if you find yourself running a lot of small unit tests try to see if you maybe can combine some of those unit tests and of course you know the goal there should be to you know make a test that better resembles how a user would use your application just try to find the right testing tool for the right problem and it's up to you as a developer or testing expert to decide upon that and especially with regard to the different types of tests because you should know that there are also other ways of testing your application for example through a combination of static tests or manual regression tests you have seen that the lines between especially unit and integration tests are you know very fine and you know don't fixate too much on the actual you know definition of what it actually means because like i said before in the community there's a lot of people that disagree what a unit or an integration test is but in the end you know the definitions it doesn't really matter as long as you're ensuring that your tests are acting as a safeguard against unwanted behavior in your apps and of course in this video i wasn't able to cover everything that is you know part of testing you also have things like mocking and you know lots of different things but i think if you understand what we've done in this video you're very well underway in your testing journey if you like to see more about react testing javascript or my live as a web developer feel free to check out my youtube channel thanks so much for staying with me and i hope you liked it and now feel you have some good tools to start testing your react applications and also brad thanks again so much for letting me create a video for your awesome channel having that said if you have any questions let me know down in the comments thanks again for watching and i hope to see you in the next one

Channel: Traversy Media

Views: 71,284

Keywords: testing, react testing, javascript testing, react testing library, jest, cypress, cypress testing

Id: OVNjsIto9xM

Length: 58min 36sec (3516 seconds)

Published: Mon Aug 30 2021

Reddit Comments

[u/therealdark]

This is great! I like your teaching style. Any chance you could so a proper full stack application course with that includes extensive testing? Put it up on Udemy or something?

[u/[deleted]]

[removed]

[u/Moonshine_90]

Nice! Added to my watch list.

[u/Mandylost]

Techbase is slowly becoming the best channel for learning react IMO and one of my favourite. And now that Brad has also supported him it clearly shows how great Mitchel is.

[u/Procyon4]

I need dis

[u/TrojinCat]

Congrats, I'll hopefully get to watch and learn from it this weekend

[u/MusicInWaves]

Thank you for this, it was a great watch, I particularly found the e2e section very interesting and informative! Question for you though, I'm new to RTL and struggling mightily at implementing at my new gig. Many of the existing components are massive and render deep component trees. I find myself spending hours just trying to setup mocks to render a component, let alone the tests themselves. Do you have any advice, tips, resources etc in regards to component mocking and global/shared mocking strategies? Thanks in advance!

[u/sunnzy]

Thank you so much for this crash course!
One question though, is $balance at 53:00 some sort of jquery object? This is my first exposure to cypress so wasn't sure. Thanks again!