Testing React apps with React Testing Library | David Armendáriz | Skillshare

Testing React apps with React Testing Library

David Armendáriz, #NeverStopLearning

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
23 Lessons (2h 50m)
    • 1. What you will learn in this course!

      0:46
    • 2. Introduction to TDD

      9:23
    • 3. Introduction to RTL

      4:01
    • 4. Create React App behind the scenes

      8:49
    • 5. Understanding Jest

      4:46
    • 6. Writing our first test

      11:22
    • 7. Rendering a component with RTL

      12:54
    • 8. Selecting elements with getByText

      7:01
    • 9. Selecting elements with getByRole

      7:53
    • 10. queryBy search variant

      6:23
    • 11. findBy search variant (Part 1)

      7:00
    • 12. findBy search variant (Part 2)

      10:11
    • 13. findBy search variant (Part 3)

      6:42
    • 14. Querying multiple elements

      6:15
    • 15. User interaction with the fireEvent function

      7:31
    • 16. User interaction with the user event API

      2:52
    • 17. Testing a component in isolation with the user event API

      8:13
    • 18. Coverage

      7:12
    • 19. Debugging

      4:28
    • 20. Creating a Pokemon component

      10:42
    • 21. Testing the Pokemon component

      10:45
    • 22. More custom matchers

      1:41
    • 23. Bonus: one of the coolest tools in software development

      12:40
16 students are watching this class

About This Class

Welcome to testing React components with React Testing Library! In this course, you will learn lots of things. You will learn:

  • The principles of Test Driven Development
  • Know what is React Testing Library (RTL) and its differences with Enzyme (another popular test framework for React)
  • Understand how Create React App (CRA) works.
  • Understand how Jest works with RTL
  • How to test with RTL and query elements with:
    • getBy, queryBy, findBy, getAllBy, queryAllBy, findAllBy
  • How to simulate user interaction with the fireEvent API
  • How to simulate user interaction with the userEvent API
  • Testing components in isolation (unit tests)
  • Learn about coverage and debugging
  • How to mock 3rd party libraries like Axios and mock a GET request
  • Learn about the pitfalls of CRA

You will have all the fundamental tools to test any React component and have that coverage at 100%!

Have fun, and never stop learning!

cef90e7c

Transcripts

1. What you will learn in this course!: Hi, in this course, you will learn the following things from testing React apps with React dusting library. What are you going to learn? The principles of test-driven development? Or typically for short, know whether react testing library RTL is and its difference with enzyme. Understand how creed React, app or CRM for sure the words understand how RTL or ingest works. Learn how to test with RGL, simulate the user interaction with RTL, learning about coverage and the bugging cotton. But third-party libraries like access and mark Get requests and much more. I hope you like this course and see you in the next video. Bye-bye. 2. Introduction to TDD: Hi and welcome to this course, Introduction to testing with React testing library or RTL for short. Funny think I once thought that RTOS right to left, but he really means reinvesting library. Okay, so we're going to learn how to test React, components and discourse. And well, it is an introduction. You're going to learn lots and lots of things. But obviously, there are many, many other things to learn. And I hope this course will help you to survive a new job, for example, that requires testing Reactome components. I am very confident that this course will help you with that. Okay, so without further ado, let's begin our journey of Destin React components. So first, what is the test EDs code you write to bear fight that behavior of your application. So simple definition. Why shall we write tests? Well, the first recently is documentation. Tests are a specification for how our coat she'll work. You can have the best developer and our right and the best documentation in their work, but nothing is better than well written tests. I'll give you an example. Suppose you have a lot of complex functions and you want to know as a new developer, what these functions are doing inside your application. So I, a well written test suite will tell you, well, dysfunction does a specific functions receive this input? This input consist of these variables. These variables have these types, and under certain conditions, this function should return this output. So that's a very, very good to have. And that's why this is the first reason of why we write tests. The second recent nice consistency. It helps to verify the software developers are following best practices and conventions for your team. A. Another example I can give you here, for example, that happens to me a lot. Is it when you write a class, you may want to do something called dependency injection. So for example, if you are embedding some other class into these class you're writing, then that is dependency injection. Okay, so why should we do this? Well, because it's easier for testing these classes because we can map them. And this is a good friends. So by running tests, if you don't do dependency injection, then you will have lots and lots of problems trying to. Test these glass you're writing. So writing tests will help you avoid these kind of problems. The third recent is confidence. So I like this analogy. A strong best suite is like a warm blanket. So you know that feeling when you are going to sleep and you have a warm blanket that is very comfortable. And tests are like that, like a warm blanket because it makes you more confident as a software developer and you feel more comfortable writing coat. Okay, so when you are, for example, Bush in some code to master, and that code obviously is going to be deployed to production. Then having that good test suite is going to avoid lots and lots of problems. Believe me. Fourth recently is productivity. We write tests because it allows us to sheep quality code faster. Ok, so some people argue that writing tests is very time-consuming. And that's right. I wouldn't argue about that. It's time consuming at first. But once you want to refactor your code in the future to make some improvements of your code. Then, believe me, having tests is going to save you a lot of time and you're going to ship better coat because of these tests. Ok, so let's quickly review the types of tests we have. We have end-to-end tests, integration tests, and unit tests. I am also including here is static type checking. And we're going to talk about this in a moment. So let's review first end-to-end tests. So these are the most complex tests you can have in your application. Because you spin up your app and see me late user behavior. It's like if you have a real Burson farming desks in your app. So these are the most complex tests, as I already told you. They are this lowest ones also, because you have sometimes to have a server running, have some database up and some other services in order to do these kinds of tests. But they test all of your app. So that's why it's called end to end use. You probably have very few of these tests because as I told you, they are the most complex. The slowest ones. Then we have integration tests and they bury fight on multiple units, work together. So remember inner react. We have components and these components can be built using some other components. So when you test this component that is made up of several other components, then you are doing an integration test. Okay? These are also somehow complex. So you have more, all of these then end-to-end tests, but less than unit tests. Unit tests verify the functionality of a single function or a component. So suppose in our React up, well you have sometimes helper functions. So you may want to best these helper function that will be a unit test or you have a single component. So suppose a presentational components, some text displayed in some cart, for example. You may want to verify that the text is rendering in jury Act obligations. So that will also be categorized as a unit test. And well, aesthetics tests. Some people may argue that these are not deaths, but they catch typos and errors while writing coat. So you may want to use flow or my favorite, which is type script in order to have these static type checking. So for example, you have breakups and you are passing some data, for example, to a presentational, a React component. You may want to verify destructor of these data. For example, if it pass it date. If these data have some, I don't know, addresses, names you may want to know also that the type of this, so for example, date will be a date type. The address will be a string, the name will also be string. So this is very, very useful and I will highly suggests to use the static types, checking in every project, your rights from now on. So it doesn't matter if it is react, he doesn't matter if it's NodeJS. If it is by him, you should have this static type checking. Okay, so that's everything I will be telling you in this lesson. I hope you liked this video and you like this journey. See you in the next one. Bye-bye. 3. Introduction to RTL: Hi and welcome back. So in this video, we're going to talk about React testing library at very, very short introduction to react testing library. So what is RTL or react tests in that way? It was created by this guy, can't see dots. And it is an alternative to Airbnb enzyme. So maybe you have heard of enzyme. This is also a framework for testing React apps. But enzyme Gibbs reactive developers, you do these tests internals of React components. So somehow the logic of the React components, while a React testing library puts the developer in the shoes of an end user. So if you come for an enzyme, you have to change your mind a little bit with a React Dustin library. We don't care about the internals of the React components. We care about how the end user interacts with these component. So this is copied from the official repo of reactants in library. And it is very clear. The problem is that if you want to write maintainable tests for your React component, then you want your tests to avoiding clean implementation details of your components and rather focus on making your tests give you the confidence for which they are intended. So as part of this, you want your test base to be maintainable in the long run so that just have your components W1 to break your tests and slow you and your team. Okay, so this last part, this, what I have already told you, tests are good. But the main thing here is that you want your test to avoid include implementation details, ok, so this is enzymes focus and rather focus on making your tests give you the confidence for which they are intended. So the solution there is these react Destin library, which is a very lively solution for Destin React components. And it provides lagged utility functions on top of Reactome. So we're going to see what this means in a later lesson. So the primary guiding present bull principle is that the more your tests reassembled away your software is used, the more confidence they can be. So pretty cool. Okay, so now let's talk a little bit about guest. Is it an alternative to react testing library? Beginners often confuse the tools for testing in react. React testing library is not an alternative to just because they actually meet each other in order to work correctly. In modern React apps, developers want to get around just for testing because it is the most popular testing framework out there. For JavaScript, it is supported by Facebook. It has a very large community, so you won't get around guest. And well, that's all. In the next video, we're going to actually see what is the difference, the real difference between just and react testing library. So I hope you like this video. See you in the next one. Bye-bye. 4. Create React App behind the scenes: Hi and welcome back. So today we're going to create a new React app. You seen type script. So we are going to change directory to our desktop. And here we're going to run the following command. Are going to use yarn, Create, React app. The name of the React app, which in my case is going to be called react testing minus-minus template type script. Okay? So now it takes some time for this to be created. But Create React tap is a tool that allows us to create a new reactor without all of these headache of configuring babble web pack and all of those things. So it comes with lots of things included. You're going to see what is included in a moment. Okay, so let's change directory to react testing. And let's open Visual Studio code here. Okay, great, so if you are new to create React app, I just wanted to show you that, for example, IEP comes already with guest. Ok, so as you can see here in the dependencies, we have testing library, just dumb. They have testing library react, and also we have dusting library, user event. Okay, so actually these are, all of these are deaf dependencies. So we can change this to a another key which is going to be called def dependencies. We're going to paste them here. Type script is also a deaf dependency because we need type script on the, when we are developing our app. And I think these ones need to be independence. Okay, so now we have separated the def, dependencies from the dependencies. The other thing I want you to notice is that here we have a scripts. So the first one that you are going to use always react up is John start. So it appends something in my browser, which by default is the space here. Okay? Okay, so let's stop here. This thing, the other thing, you're going to use, this darn built, which is going to give you an optimized production deal, as it says here. Okay, so now you have here built folder, which is going to have this index, that HTML, which is basically your whole app. Along with, for example, these. Static assets, which contains some JavaScript, CSS. What else? You have? These? Service worker, which is important if you want to create a progressive web app, for example, and the fabric and many, many other things. Ok. So this builds folder isn't that good ignores because we don't need, we don't need this folder in our repository. So it's okay if it is in the gitignore. Also Node modules is in gitignore. And well, we also the test, which we're going to know more about this in a moment. And I also wanted to show you that we have these jarring eject. So for teaching purposes, that's jarring object. And it says, are you sure you want to reject this action is permanent? I'm going to say yes. Ok, so we have these untracked files. So we're going to first add this package JSON with good, good at package.json are going to say, I'm moved. Some dependencies. From the dependence you can, you can put whatever commit message. By the way, I have this good ci because I have a good aliased. But you can say git commit. Well, we didn't have anywhere to push this commit, so we're going to stay like that. Okay? So now we can eject and we're going to say yes. And as you can see, Luke would happen here. Now we have in our dependencies, we have lots of things that we had before. For example, variable, we have this label jazz people loader. I think we have in that we have wept bag also. You have December We have this Sass loader. We have passed CSS, so lots of things that we didn't have before. So this is what React is hiding from us when we create a new React app with Create React. So the idea behind Create React app is to hide all of these configuration that is very, very cumbersome. Because, you know, look at all of these things. It's very, very cumbersome to start the React app from 0. But maybe you are working in a very, very big project. You may need to eject everything by using this jar reject command. And well, you can see that darn tests behind the scenes is node scripts dest dot js. And the scripts we have here this three files. So when, whenever you do jargons start, you are doing everything. Here. Look at all this. Messy thinks. So this is what happens when you run jhanas start. This is what happens when you run jargon test, and this is what happens when you use yarn built. So create a React app, hides all of this complexity for us. Well, we have also this config files. I don't know what they do, to be honest. So I'm going to leave it like that. And I'm going to undo all of these things by doing git stash. Okay, so now we have our package, Jason is now like before, so we have the best dependencies, remember? And well, these changes are here in these stash. So that's what git stash thus. So we're going to stash clear and it's like nothing happened. Okay. So I think that's all for this video. I just wanted to show you what is happening when you create a new React app. With Create React app, you have to be aware of, you want to be a successful react developer. And well, I'm going to actually write some tests in the next video. So I hope you liked this video. See you in the next one. Bye-bye. 5. Understanding Jest: Hi and welcome back. So last time we saw what Create React app does behind the scenes. We also move some dependencies to dev dependencies. So just to be clear, these three deaf dependencies here are specific to react testing library. So that means that Create React app also comes with React testing library. And that's cool because that means that Facebook recommends react testing library. In order to set up our tests. We also have the Stef dependencies types just So that's specific to just and it is there because we needed in order for just to work appropriately with that script. That is also a deaf dependency because we only need that script for developing our app. Because at the end of the day when we run jarring bill, that's going to be pure JavaScript because you know, the browser only understands JavaScript. It doesn't understand Type Script. It doesn't understand anything besides HTML, CSS, CSS, and JavaScript, sorry, JavaScript. And well, we also have scripts, we have test. And we, we already saw that these scripts are very complex files that Create, React up hides all of this complexity for us. And it tells us, hey, if you want to run your tests, then simply run jarring test. And as you can see, no tests found related to files changed since last commit. So this is going to run only the tests related to files that we have changed. But we can still run all of the tests if we press a. So let's press a. And as you can see, these test passed. So that screen, and we have only one test suite and only one test. And this is the time it took 1, 14 seconds. Okay, so now let's see what is happened here. You can see that first we need to name our files with these dot dot TSX. That's how justice going to recognize that this is indeed a test. If for example, we change, this file will be safe. You can see that now this is going to run again because we are changing this file. Okay, so let's reload this again. And well here we are using this render method which uses specific from React testing Larry. And don't worry if you don't understand what is happening here. I just wanted to show you what is an actual or react test. You can also see that I have these little green check and that is because I have the slugging installed, which is just so you can also install it. Dcs from Facebook. So look at all of those downloads. It's very, very useful because you don't need this anymore. Of course you may want to use it, but sometimes you just want to see, hey, these best bath, we have a green check here. And that's what these extension, thus, it thus mar thinks, but that's the main feature. Okay, so that's everything for this video. We're going to actually write the test in the next one. So see you in the next video. I hope you liked this one. Bye-bye. 6. Writing our first test: Hi and welcome back. So today we're going to outlast, right, our first test. Okay. So remember that created react tap, MAPE or king with this desk by default. And it's called AP test that TSX. Because remember, all tests must end with the suffix that test_data, TSX or dot test.js. If you're writing, if you are not testing a, a React component, but they simple function. And in fact, that's where we're going to do in this video. We're not going to test a React component yet. We're going to first see some basics of testing by destiny, a simple function that sums to positive numbers. Okay, so let's create a new file that is going to be called Example dot Best dot ts. So it's the ASP because as I told you, are not going to test the red component yet. Okay, so I'm going to show you in this lesson two important things. The first one is the principles of TDD or test-driven development. And the second thing is how to name your tests, because it's very, very important that you follow a convention. There are multiple, multiple conventions out there. I'm going to show you just one of them that I like to use. And it's very important because other developers will understand what is happening with your tests. And remember that that's our documentation. And documentation must be well written even if it has a form of test or if it's a document, anything you want, it has to be well-written. Okay, so I have this theme and toward you. So this is test-driven development. In a nutshell. The first step is write a failing test. Then make the test pass by writing the minimum coat in order for this test to pass. Then you can refactor your code. And maybe in that refactoring process, you're going to make the test fail again. So you must make the test pass again. So this is TDD in a nutshell, okay? But I'm going to be 100% honest with you. There are great developers out there that know a lot more than me about testing. And they don't follow with this. Even if TDD says, hey, you shall do it like this. There are lots of people that didn't, don't do this for teaching purposes. I'm going to in this video do it like that. But maybe in future beat is I'm not going to do it like that because people are accustomed to write code first. And that's a, a very, very string had it. And well, you cannot make people change their mind from one day to another. So that's something I must tell you. But as I told you in this lesson, I will, at least in this lesson, I'm going to do it like that. So first we're going to write our test suite. So for that, you write or you use these describe. And here you're going to describe what is going to happen with your test. Inside this describe block, you're going to have all your test cases that describe is also called a desk treat. And obviously inside your tests, you're going to have your multiple test cases. And remember that the tests are inside these tests block. Ok, so as I told you earlier, are going to make a simple function that sums to positive numbers. So I'm going to say here, when the arguments passed are busted numbers. Okay? Now, inside the describe block, who are going to actually write her best cases. And the best cases. Shold, start with a word hilt. So Schulte, or turn the right tensor. Fine. And now we're going to write the assertion. So the assertion ingest is generally written that with these expect statement and expect to where I'm going to call our function. That is going to be some bus diff numbers. Okay? So we're going to pass the number four and number five. And this is supposed to be nine. So this is called a matcher. That 2B and the seas, the expected statement. Ok, fine. Now, well, obviously these test, thus not bass because we haven't written the function. So let's write the function now. So guns, some positive numbers are going to receive Number one of type, sorry of type number and number two of type number as well. Now let's return number one plus number two. And now these test basses, here we have these little error that says all files must be modules when the isolated modules flag is provided. Well, this is some type script thing that I can configure in these Ts conflict adjacent. Then the worry, it's just because I need some import or export something or my configuration right now I see it is going to, to throw that error, okay? So that's not something you should care. The important thing here is that the best, best. Now, let's writing another test. And well, not here. Let's write another test suite. And then I'm going to say here when one of the arguments is a negative number. Okay? And we're going to say here, shoud that o and error. Ok. So there are multiple, multiple ways, lots and lots of ways to verify if a function is throwing an error. I'm going to show you just one of those multiple ways. So I usually do the following. I declare these error. Then I wrap my function inside these try-catch block. For example, I can say some positive numbers and we're going to say minus 15. And well, I say error is going to be equal to air. And then outside that catch, there are going to say expect error to be defined. Sorry, to be defined. And well, there are, as I told you, there are multiple ways of doing that. You can put these expecting side the sketch. And the Right. Now, our test is not going to pass because as you can see, we have here that the received value is undefined. So undefined is not defined. So you can also pass John desk for example. And it's going to show you that one desk failed. Okay, because we received on the fine. So let's make this function, Let's refactor. So now we're in this part of DVD. Let's refactor and say if number one is less than 0, or number two is less than 0, and we are going to throw a new error. Okay? One of the numbers is negative. I'm now our test is passing. Okay? You can also do, for example, expect error that message to be. And you can pass these error message. And these had expect the statement is not going to fail. So I think that's the core thing about this. Of course, you won't have these some positive numbers here. You're going to have these in another file. So let's put these Indian, Indian other file, sample.txt file. And let's copy this function here and here. And here where I'm going to say import some positive numbers. Okay, so the VS code already did it for me. It's not export that. Well, it is exported. Some positive numbers. Muddle exampled that test. Okay, so it's not from example dot test, it's only from example. That's why it was failed. Ok. That's all. And I hope you liked this video. See you in the next one by y. 7. Rendering a component with RTL: Hi and welcome back. So today we're going to actually test our first React component. But before doing that, we're going to do some important thing. I have noticed that by the time I am recording this video, there are some dependencies that are I'll date it, so we're going to upgrade it. It's very easy just to run jarring, upgrade, dash, dash latest. And let's wait for these two. Great, all of our dependencies. So just run this command when you are 100% sure that you're not going to break your app. Okay, so well, this is the output. I don't care about this. Let's see the changes. As you can see, these types note God from version to version of 14. So that's a major change. These one got from 16 dot 90216 dot 950. So that's a batch. Actually, it's not a big deal. And all of the dev dependencies were upgraded to meet your versions. You can see from four to five, from nine to 11, from seven to 12, from 24 to 26, and from three to four. So those are very important changes. I don't know why Create React app is not creating your app with these dependencies upgraded. So that's maybe an issue, but then worry, we, we already fixed this by running that command. Okay, fine. Now let's go to the app.js, ESX, and let's get rid of all of these things. And that's get the rate of this logo. And that split here inside this div, something simple thing like RTL. Okay, so now our test is broken, but don't worry because we're going to delete it and we're going to create a new desk sit. So remember, in order to do that, we just need this describe. And we're going to say when everything is OK. And now we're going to write our test case. Remember, it should start with the word shoot, shoot, render the App component without crashing. Now, here we're going to say render. And now as you can see, the test is passing. So you may be asking yourself, where is the expect a statement whereas the assertion Bart here. So sometimes you cannot put unexpected statement and this is called implicit assertion. Why? Because you're not putting any type of statement. When you put an expected statement, then this is called an explicit assertion. So that's some terminology because where I'm behind the scenes actually testing these, where we're testing that the App component is rendering without crashing. And we don't need any expect the statement here. If there were any problems, then these test will not pass. This will throw an error and we shall fix what is causing that error. Ok, so that's fine. Now I am going to show you something magic from testing library react. We have these screen and we're going to say a screenshot debug. And let's actually iran John test. So jarring best. And as you can see, we have here the actual HTML output. And you may be asking yourself where these body and these deep came from. Well, every time we render some component with a render method, it will add this container automatically for us. So this body and this div come from this render method and this last div with RTL. He's obviously our app component. So remember this is not this x, this is actually HTML, pure HTML. Okay, so now let's see what this screenshot debug, thus bat with a more complex component. Okay, so let's delete this for a moment, and let's actually create a new component, but with more things. So for example, with this, That's not called texts. Let's call it search, sorry, let's call it text and set the text. Okay? And we're going to say use the states are going to bass and an empty string. And we're going to create a function called handled change. And will change, which is going to take an event and is going to set the text to event dot target data value. Okay? And let's return some diff. But before doing that, let's create another component that is going to be outside this app component. So let's call it search or search, maybe custom input, if you want to say that the custom input, and it's going to receive a value, it's going to receive, well, first some children than a value and then an onchange function. Here we're going to return. A diff with some label, HTML or search. Okay? And then an input. And that's going to be of type text. And we're going to set an idea of search. Here. We're going to render the children, which can be any text. And we also here need a value and also need an onchange, which is going to be to the same unchanged with Beth to prompts. Okay, fine. Now, type script ys is complaining about the types of these props. So before assigning the types, let's complete. Here are dif. So here we're going to say Gustaf input. We have to pass a value which is going to be search the unchanged, which is going to be the handle change. And inside, this is the children. So not search. We have search in my mind input. And here we're going to put beam. Say you typed. And here we're going to say search. You search exists. Search otherwise, just put three dots there. Okay, so again, I don't know why I have search in my mind. This shall be text actually. Ok. Now it's not complete. By the way. Here. This can be simplified by just saying double-quotes. And this is saying if texts exist, then render this thing. Otherwise, just if text is an empty string, put three dots. Okay, fine. Now let's, let's first correct this event. This event is of type react that change event. We have to say HTML input element. And here we're going to define a new type or a new interface, whatever you want. Custom input for ops and children is going to be of type, react, react, note value of type string. And on change is going to be a function that receives an event which is of type, react dot, change event, HTML input element, and it returns nothing. So it's a dive boat. And here we're going to say custom input props. And that's all. Now let's see. What's the actual output of this. Okay, so we have here are very simple inputs. Let's say it's towers. You type the Star Wars, so nothing too fancy, nothing too complicated. And our test is still passing. Now let's see what the output of this thing is. So let's run Yarn test. And let's open these side-by-side just to see what's happening here. Well, actually we don't need it side-by-side. We can have it here and here. Okay, so the first thing you need to notice is that we have this body and these DEF, remember these are put automatically by the render method. And we have this first div that is from our component. It corresponds to this div. Now, this is day effects, so this won't be in the pure HTML output, but this div is going to be this div, this label is going to be this label. Notice that here we have HTML4 because that's reacts syntax. But in the, in the HTML output, we just have these four. Natalie have this input. And here this input is this input. We have the ID that typed and the value. We didn't have the unchanged because obviously this is React. And notice that the value right now is an empty string because the HTML needs a value. And now we have the spectrograph which corresponds to this one. And it says You typed and empty string. Because again, this is the static HTML output. So I think the video is getting too long. I just wanted to show you how this screenshot debug method worked. And it's very, very useful because I'm, you're going to see the actual HTML output. Okay, that's fine. I hope you liked this video. See you in the next one. Bye-bye. 8. Selecting elements with getByText: Hi and welcome back. So today we're going to learn how to select elements in our React tests. Ok, so remember that we build these component here, which is a little more complex. And we created also these Kusama input and we pass these children, which right now is just a simple text. And let's remember what these component it. So as you can see, we can put our input here and it's going to show you that text onscreen. So nothing too fancy, nothing too complicated. So we want to to see that this thing here is actually being rendered. So let's go to our app.js test.js EXE file and add another test. So we have here under the scribe, which is the test suite, when everything is okay, we shold select DOM children that is being passed as to that custom input components. So very specific. Everyone, Ranger test should understand that we are referring to this thing here. Okay, so lets first render our app. Fine. Now, let's actually use something from this screen that we imported. So to screen that Good-bye texts. And we're going to pass the data, the text which is input. I'm just going to copy and paste this in here. Ok, so that test, right now, he's passing. Why? Because we are using an implicit assertion here. So remember, than implicit assertion is when we assert something without using an expect the statement. So how are we able to do that? We get by text. Well, good-bye texts throws an error. If on the text to you bass here is not found in the document. So for example, if I delete this column and I hit save and wait for a moment. Now, you can see here that the desk is not passing. And if you hover with the mouse here, you can see that Unable to find an element with text input, these could be because of text is broken up by multiple elements, bla, bla, bla, bla. And you can see actually the HTML output that we can also see with the screenshot debug method. And we can see that here input. Is like this. So I put back the column, then it's going to pass. And then we can make can explicit assertion also by saying as green dot, good-bye text. And pass input. And say, this needs to be in the document. Okay, fine. So now it is passing and we are using an implicit, sorry, inexplicit assertion here. Okay? So suppose I delete the column here. So now it's not passing again. So you may expect that if I put here not to be in the document, this is going to pass. But the thing is that this isn't a passing. Why? Well, because this is throwing an error. So we can, we can we can do this because this is throwing an error. Well, we can do is put this in a try-catch. For example, try catch error. And remember how I did in one of my videos, I said error equal to this thing here. And actually with this thing here. And then say expect error to be the find. I'm now these is passing. Why? Because this goes, these throws an error. The error is catched. Now the error is assigned to this variable error. I'm now the error is defined, so this is true. Okay, so that's how you would test that. This is not in the document. Okay. But we're going to delete this and they with this line here. Okay, so a, another thing you need to know is that you can pass a string or you can pass a regular expression. So in order to do that, we just simply go to the regular expression between these two slashes. And I can say input. And the test is going to B_s because we're not doing an exact match or just verifying that something that contains input, that text input is being rendered. And well, it is, it's this part here. So this test is going to pass. So this is everything for this video. Regular expressions. I know they are nasty, but in this case, they can be very, very powerful for testing. So I hope you liked this video. We are going to learn a lot more about these methods and see you in the next video. Bye-bye. 9. Selecting elements with getByRole: Hi and welcome back. So today we're going to learn about another important function which is get by role. So we have already learned about good-bye text, where the text is one of the several search types we have, but we also have other search types. And the other one that is very used is the roll. And we can search by rho with these get barrel function. So these get viral function is usually used to retrieve elements by area labeled attributes. But there are also implicit their roles on HTML elements like the bottom, for example, for a button element. Here, we didn't have a bottom that we have some other things like an input. So let see what the role for the input is. We're going to see that in a moment. Thus, we can select these elements not only by their text with good-bye texts, but also by their accessibility role with React testing labor. So let's write another test. We're going to say should select the input element by its role. And here we're going to render again our app as usual. And we're going to say is screen, get by row. And first we're going to pass whatever here. And this is going to fail. Okay, but the advantage of this is that React testing Larry is like type script if you want to say that because it is suggesting us what are the roles percentage in the component. So it says, unable to find an accessible element with a role, whatever. Obviously, here are the accessible heroes backs box and it has this name input. And it is showing us the input components. So the textbox is referring to the input component. So let's put here Xbox. And now EDs passing because we have a text box, which in this case is an input component. So again, we are doing some implicit assertion because we're not having any expected statement. But if you want, we can put some expected statement here. Screen, get by role, text box to be in the document. Okay, fine. So. This is also going to bass. Remember, if we put anything here like whatever, this is going to throw an error. So you cannot just put not to be in the document. You have to do that try-catch trick that I already showed you in the last video. So let's put again the correct role, which is textbooks. So as I told you, this is usually for searching, be Ardea label attributes of what. It is not necessary to assign roles to HTML elements explicitly, because the DOM already has implicit roles attached to some HTML elements. And this is why good-bye role is a strong contender to get by text search function from React testing. We also have other search types. For example, for the label. We can say here, shoot, select a label element by its text. So again, we're going to render our, we render our app and then say screen, get by labeled text. And in our case, our labeled text is these children. And these children in these case is this input element. Input text, sorry. Okay, so this test is passing. This test is equivalent to the first two that Well to the second one. But here we are searching by text so it can be anything. And here we are searching by labeled text. So a specifically to these labeled component here. We can also select by placeholders. So she will select input element by placeholder text. So again, let's write ab. And let's say screen get. This is by placeholder text. And we're going to say example. Okay, so this test is failing because obviously we don't have a place holder. But we can assign one place holder to be example. So now the test is passing. So we are actually doing the React, sorry that TDD cycle. So remember, we first derived a test that fails, then we make the test pass and refactor code. So we are respecting that in these case, we can also, we have more methods. But let's stop there. And notice one thing. See that in every test we are rendering our app. So this is becoming very repetitive. So we can avoid that by saying before h. And these also accepts an arrow function. So before each, render our app. So we can now delete this, this, this, this, and delete this. Now we didn't have that repetition. And this is very, very useful because it is now rendering our app in each of our test cases. Okay, so that's everything. For this video, we're going to learn more and more interesting things. So I hope you liked this video and see you in the next one. Bye-bye. 10. queryBy search variant: Hi and welcome back. So today we are going to learn some search variants. In contrast to search types. There are also search barons. And one of them is good-bye. And we have already done lots of things with good-bye. We have goodbye text and get my role. Those are the search types. But we also have search variants like the one we're going to learn today which is query by. There is also fine by, are going to learn how these works. And Well, just to say both of them can be extended by the same search types that get by S axis. For example, curry by, we also have query by text. We also have query by role, query by labeled text, query by placeholder text. We have many, many other assert church type like createdBy alt text for images and query by display value. Okay, so let's see what's the difference between, um, and good-bye and query by. So let's create a nother desk. And it's going to be the same as these one. So it should select. Let's use query by role. For example, she'll select the input element by its role with query by role. Ok. So now, remember, now we don't have to render our app because this is done in these before each. But we can still do query by row and put the x box here. Okay? And now this test passes, but what happens if I boot whatever here? Now, the test is not failing. So remember if we do this with get viral, that test is going to fail because these throws an error. So in contrast, query by role and everything that starts with query is not going to throw an error. So let's assign this to a variable called result. And just for the gin purposes, let's see what is the output of this result. So that's run darn test. And we have here in this watch usage, we have several options. Let's press the T to filter by a test name, regex butter. So I'm just going to say query by. Roll. And well, it's a reg ex. So it's going to only run the tests that has query by role in the description. So these one here, Shultz elect they input element by its role with query by role. And we have these console lock, which is this console log obviously, and it is null. So that means that when query by role doesn't find a role, then it's going to print or return null. So let's again do this and we can do an explicit assertion to, for example, if I put whatever here. Now, I can say here to be null because we are confident that Eve, these element is not in our component. This role is not enough in our component, then this is going to be no. But if I put decks to bucks, bucks, then the test he's not going to pass because this is not null anymore. Okay? So we should rename the name of this desk. Are going to say, shold, return. No, shall not find the role, whatever double-quotes in our component. So we are going to say whatever. And now the test is passing. So this is very useful in order to assert the elements which aren't there. Remember that I also taught you how to do this with a try-catch login using git by rolled in these, in these case. And well, it's better. And we write less lands of goats. Iv, we simply use query by role because we didn't have to wrap the Good-bye role in a try-catch than catching the error and then asserting that the error is defined. So this is a better alternative to that approach. Okay, so that's everything for this video. I hope you like it and see you in the next one. Bye-bye. 11. findBy search variant (Part 1): Hi and welcome back. Today we're going to learn about another search, Baron, which is fine by however, before doing this, we need to do something. Because by the time I'm recording this video, there are some problems with great React app that is using an updated version of just environment JS DOM. So this is actually very easy to fix. Let's do this by adding this bef dependency, which is just environment JS DOM 16. So Create tab is a great tool that it also has many flaws. Okay, now we have to modify little bit our test script and add here just environment. Days DOM 16. Okay? Now, our tests are not going to fail when we around John test, however, they are going to fail with our plugging with are just plugging from BS code. So let's create, just config that js file. That's great, this file. And here we're going to export this thing here, which is the test environment and environment. And it's going to be the same as just an environment, j's DOM 16. Now, we're going to have feedback also from this blogging that we installed. Okay, so where you are going to learn the fine by search variant. And the first thing you need to know is that it is used for asynchronous elements, which will be there eventually. So we're going to modify our app component a little bit. We're going to fetch a user from a mocked API. The API is going to return the promise which is going to resolve with a user object. And the component then is going to store these user from the promise to the components date. And then the component is going to rerender because we are, we are updating the state. And after all of this, there's going to be some conditional rendering that is going to show some text if the user is not null. So let's do this actually by creating first a function called Get User. So no arguments. And this is going to be our mult API, which is going to return a promise that resolve to a user object, which is going to be or is going to have an ID and a name, which in this case it's my name, w. Ok, so it's important to have a type, a return type. So this is going to return a user. And this user has an ID which is a string. And let's make this an interface in case we want to extense these user interface. And the name is also going to be a string. So it is not necessary, but I suggest you to return a promise of user, ok, so this can also throw an error. It depends on your type script configuration. Some people like to say, hey, all of your functions need to have a return type. In my case, or in the case of grade react tab. I don't think that that is a default configuration. Okay, now let's create a user state. You sir, and sit user uses state. And the type of this thing is going to be of type user or null, either of those. So it's going to be initialized with null. Okay? And then we're going to fetch our API. So we are going to use, use effect with an empty array of dependencies. So this is going to simulate the component did mount lifecycle method. If you are familiar with class components. And here we're going to create an async function, which is going to be fetch user. So it's going to be a sink. And here we're going to await for our user, which comes from our getUser function. And we're going to set the user, this user, and don't forget to call this function. Okay, fine. Now, this is going to rerender M. We're going to conditionally render these user or some text. So here we're going to say username. You sir, dot name. Otherwise, do not render anything or render null. Ok, so now our component is modified. Now let's see what is happening here with Jorn test. Sorry jarring, start. And as you can see, I have now here username David, we have our input and you typed. So if I refresh this page, so it's very, very fast, but there is some time that this is not being rendered because we need to fetch our false API. So we want to test that. We wanted to test that in the initial render. This thing is not being displayed. And then after fetching our API, this thing appears. Ok. So that's what we're going to do in the next video. I think it's getting too long. So see you in next video. Bye bye. 12. findBy search variant (Part 2): Hi and welcome back. So today we're going to still learn how to use the find by search burn. But before doing that, we need to do several things first. So remember in our last video that these tests are passing. However, if we run urine test and run all tests, now you're going to see that we have lots of warnings. I mean, all of the tests passed, but we have all of these warnings. So they are just warnings. However, they are important warnings. Why? Because nowhere having side effects, because we have a huge effect and these can cause lots of side effects to our component. So this is a way for us to write more meaningful tests. Because for example, here we are saying, Hey, do you have get by text in your component? Well, the answer is yes, but what happens after we have fetched the API? What happens? These good-bye texts? It gets loaded, it's still there. So all of these questions arise to our mind when we are writing these kinds of components. And these warnings are a way to say, Hey, you may want to write more meaningful tests. So let's go to our app.js ESX, and let's do a little reflector here. Let's create this, get a user file. And here we're going to put our getUser function and our interface. Now we are exporting the interface and the get user function. Here. Let's import the also the user interface and the get user function. Fine. Now, it is going to be easier for us to mug these. Get you, sir. Function. So right now for teaching purposes, VCs simply returning a promise that these were solving immediately. But in a React app, in a, well, any project from your work, this is not going to be a promise dot Resolve. It's going to probably be a GET request done with that serious to some API. And obviously in your tests, you won't be hidden the API because, well, multiple reasons. The first one is that your tests are going to be slower. Also. For example, the feeds, a paid API. Then you are going to heat this API and each of these requests is going to cost you money and you want like that. So we need. To mark these getUser function, I bet on by putting the get user function in this file, it's going to be easier to mock it. So let's actually do that. And that's go to our test. And let's import from the getUser file. Let's import the get user function. Now let's mock this thing by simply saying just dot-com. Ok, get user. So the path of the file, okay, now this get user, in theory, it is now mocked. However, there is an issue with that script that this doesn't add the MCQ types to get user. So in theory, if we would like to do something like get you sir dot mock implementation or, or get the user more clear. We want be able to do that because type script is going to complain. So there is a simple workaround. We have to install these deaf dependency called T S desk. Fine. Now we have the SDS and we can create a mock, a MLT or MAC getUser, and mocked get the user. And I'm going to explain to you these true parameter. But first, let's import mocked from TS, just slash utils. Ok, so this true here means that for example, if we were returning instead of a promise, we were returning an object. And each key value of this object is a function, for example. Then this is going, sorry, this is going to say you have to clone or make a deep mock of this thing here. I mean, all of the functions inside this object also need to be mocked. Fine. Now, we can do the following. We can make these foreach async. And we can say now a weight. And we're going to use another thing from testing Lyra react, which is gold. Wait for ok. And as the name suggests, are going to wait for something to happen. So wait for the, receives a call back. And we are going to say, expect, Mont, get, sorry, mock, get, user to have been cold. So we are waiting basically for this thing to have been called. Fine. Now let's run jarring test again. Now the tests are passing, but we didn't have all of those warnings. Why? Because now we are waiting for something to happen in our component and testing what is happening. After this thing has been called. In this case, the MAC get user, which is just the get user function. Okay, fine. So now we are not having all of those, all of those warnings are we are now going to make another test suite. We're going to say describe. And we're going to say when the component, when the component fetches the user successfully. Okay. In the before each, we're going to clear the MAC. So Mark, did you sir, now has this clear method. Okay. And in our tests, in our test, we're going to say Sure, called Get User once. So we want to be sure that our, our API called is just being called once. So we are going to render the app because these beforeEach only applies to these describe block. This is another describe block. So we need this render app and we're going to wait, wait for. So it's basically the same thing. Expect MET, malloc, get the user to have been called times one. Right? Now, our test is passing. And we are sure that we are calling the API just one type. So that's cool because we wouldn't like to call the API multiple times. For the reasons I already told you one will be an economical reason. If the API is spade, then you will like to minimize the, the, the number of times that you are calling this API. So that's great. Also, note that here we are using an expect a statement, although this is not a test, and that's fine. We're just waiting for this thing to have been cooled. Okay. Well, that's everything for this video. I think it's getting long the video. But I can say now that in the next video we're going to learn about the find by search burned. So see you in that video. Bye-bye. 13. findBy search variant (Part 3): Hi and welcome back. So finally, we have everything to use the fine by search event. So let's actually create a nother test. And I don't know what to put here. Maybe. Okay. Shold render. And let me remember what I put here. Ok, they username shold, render, the username past. Ok. So we have our acid function and we can actually do very interesting things here. So remember last time we marked our get you sir function. So now we can make an implementation like this. So let's mock, get user, that mock implementation once. And here we can say return, promise, I'm sorry. I can just say Brahmins dot resolve. And I couldn't put here ID one and name. Whatever you want. You can say John instead of David, that it was here like that. So we can change actually this and remember, this is going to be a natural get request, Boston request, I don't know. And here we can Mm-hm. Manipulate this function however we want. Okay, so now we're rendering our app. Now let's write expect screen dot. Let's query by text. And let's say username to be null. So remember, in the initial render this is going to be null. So this is not going to render users know. Thus this is not going to render. But after that, we're going to wait. And now we're going to use find by text. The same thing, username to be in the document. And here we need another slush. And now the test is passing. So that school. Now let's do something more. Let's see what the screenshot debug is throwing us before these 08 and after these awaits. So remember. We can write jarring test and we can filter by this description. So I'm going to say a render username. And here, actually just this helping me to find a test. Okay, so let's see. Screened the buck. This is before these await. You gotta see this is the output HTML. Let's this bigger. And after the 08, we have these username and John here, we didn't have that username, John. Okay, so that's very, very cool. In fact, let's delete this and let's put here user name, John. That's reuse these. Let's actually put it only name, name. And we can say, expect the same thing, screen, find by text and say, well, actually just to name two being the document. Okay, so now this is failing, unable to find the element with text. Let's just put this in here, like this. And now it is working as expected. So name actually these jumps so it can't find John into documents. So that's cool because now we are sure that John the name John is in the document. So how cool is that? That's how fine by text works. And this is how you make a mock implementation of these get user mark. There is actually some syntactic sugar here. We can simply say mock. And I think it's resolved value once and simply put ID one and name. And it's actually the same thing, but we don't have to define the function. We that returns a promise. This is like a shortcut for that. Okay, so I hope you liked this video. And remember one thing more, find a text. You also have find by role, find by old text, find by labeled text, find by placeholder text, find by display value, and find by test ID. So it's the same as the good-bye and the query by. But this is used with an a weight because this is for asynchronous elements. As I told you in the first part of this series of videos. Well, I hope you liked this video and see you in the next one. Bye bye. 14. Querying multiple elements: Hi and welcome back. Today we're going to learn yet another search variant, which is extremely, extremely useful and you must, you need to know this. So let's take this custom input and let's duplicate. So just copy and paste this thing. Now let's go to our app. Test that TSX and you can see that now some tests are failing. Okay, so let's hover and see what the error is. It says testing library element, there're found multiple elements with a text input. Here are the matching elements. So we have these label with this input text and this label with these input texts. So remember this is the actual HTML output. If this is intentional, then use the old bivariant of the query. Like query all the text gets old by text or find all by text. And that's exactly what we are going to do. So this get all bypassed. He's now going to catch all of the elements that contains these input. In our case, those are label elements, these things here. So now our test is passing because get by text is just going to return. It's going to throw an error if Eve, it finds more than one element and get all by text, is not going to do that. Okay? Now shoots, lags the input element by its row. We can do the same thing here. Get o by rho, get all by role. Now this test is not passing. Let's hover and CD era. And you can see here, received value must be an HTML element or an S VEG element. Received has type array. And the array, the array is this thing here. Received has value and we have an array of inputs. So that's interesting. And we can actually do several things here. We can, for example, test if the first element using the document, now it is passing. And we can duplicate this thing and test if the second element using the document. If you have lots and lumps, then you may want to do a for loop, for example, and test that all of those things are in the document. But another interesting test is that you can do this thing here and say length to equal. Okay, so lets rub these like this. Hope that all sorry, I have get all by text, get o by rho. So now it should work. So I think these last test is a more interesting because now you are sure that you have two elements, exactly two and not more than two of these custom input. So this is very, very useful. For example, if you want to make an infinite scroll and you want to first show, for example, the first five elements and thinks like that. I think these tests is more meaningful. Again. Now, let's go to the next, to the next test. Ea here it says, should select the label element by its text. And as you can see, good, by labeled text without the good old bi is passing. So why is this happening? It looks like this thing is in the HTML output once. Or at least. This is how the React testing library thinks. So that's sprint, debug and see jar test. Ok, so one is failing lead sexually search for this test, which is label element. Ok, so as you can see, we have here these label and these label. But for React testing library, it's only one label because it's the same label. For search, they have the same four attributes. So React testing library East considering that this is the same label. So pretty interesting. And finally, we have these get by placeholder text. And if we change these to get all by placeholder text, then our tests are passing again. So Ronald tests, and as you can see, eight tests passed. So very cool and very useful also. So that's the other search burnt I wanted to show you. I hope you liked this video and see you in the next one. Bye-bye. 15. User interaction with the fireEvent function: Hi and welcome back. So, so far we have only tested whether elements are rendered or not in a React component with good-bye and query by. And whether re-rendered React components has the desired elements by using fine by. But what about user interaction? So remember, in the first videos that I told you that enzyme is different from React testing library. Enzyme folk use on the internals of React components while reactors in library focused on the user interaction. So we need to learn about that, and that's what we're going to learn in this video. So for example, if a user types into the input field that we have here, then the component is going to re-render and the new value shall be displayed in the screen. So in React testing library, we have a Feyerabend function to simulate the interaction of an end-user. So let's see how this works. But before doing that, let's delete this thing here. So we're going to delete that duplicate. And as you can see now, some test, well, only this test is failing. Why? Well, because now get all by role or returns on the array, still returning an array, but it only has one element though. So let's delete this thing. And now the length of this array is one. So if we make these changes, now this test is passing. And this is also a bad thing because this is an implicit assertion. So DRA, of, I think it's labels here exists. So this is not going to throw an error. The same thing here. The array of, I think it's input here exists. So this is not going to throw any error. So all of our tests are passing. Great. Now, let's write another test suite with the describe block and say when the user enter some text in the input element, then it should display the text on the screen. Are going to make this an a sinc function. Because remember, now our app is using these US effects, so we need to wait for something. Let's copy this thing here. And based it here. Now, right now this is going to fail. Why? Let's see the error AT saying the expected number of goals is one, but received a number of goals too. So white too. Well in these last desk. So remember this before each is resetting the number of coals to the user or to the mug get a user. So here, after this test, the mug reducer. Was gold once and we render the app it's gold twice. So actually, we didn't care about the number of times that this thing has been gold. So we're just going to say to have been called. Now our test is passing, but that's not our test. Actually. Our test is going to be we need to first import the fire bent. So the Feyerabend, these bars, these Destin never react. And here we're going to save far event that change. And now we're going to say screen get by role. We're going to get the text box here. And as the second argument, the thing we want to type. And how do we say that? Well, target value. And you can put anything here. I'm going to put my name. So why target value? Remember that we have this handled change function that takes from the event, the target property and from the target property, the value property. So that's what we're doing here. Well, after that, we need to assert something. We need to assert that that text is displayed in the screen. So we can do that with get by text. And we're going to say you typed, you typed it. And our test is passing. This is not throwing an error, but it will be interesting also to see what is showing before doing this event. So in theory, this needs to be displayed. You typed if text is an empty string, it should display these three dots. But as you can see, our test, a snob passing. So let's jhanas start this app and see what is happening. So in fact, indeed, the three dots aren't showing. Hmm interesting. So we must refactor our code. So when I did this, I thought these will work. But we're seeing via a test that this is actually another working. So we're going to do this like this. So and now our test is running. He's passing, sorry. And let's again do jargons start. And now we can see that the three dots are, are displayed in the screen. But if I enter something, then the three dots disappear. And what is splitting the input is showing on the screen. So this is something that I didn't think about. I just realized right now. And as you can see, that test helped me to see these error. So that's very, very cool. Okay, so that's everything I wanted to show you about the far event function. But there's something better that the Feyerabend and that what we are going to see next. So I hope you liked this video. See you in the next one. Bye-bye. 16. User interaction with the user event API: Hi and welcome back. Today we're going to talk about the user event. So let's see at our dependencies, we have here testing library, user event. So this user event library is built on top of the fire event API. And remember that in the last video we used the Feyerabend to trigger user interactions. But now we're going to use the user event as a replacement because the user event API is more accurate, so it mimics the actual browser behavior more closely than the varmint API. And remember that's always what we are searching for with React testing library. So for example, the Feyerabend change that we have here triggers only a change event. Whereas the servant dot type that we're going to see in a moment triggers and change event, but can also trigger a key down, a keypress and keyup events. So it's more realistic. So we're just going to replace, we're not going to use Feyerabend anymore. And we're going to import user event from testing leverage user event and remember, testing library user events, gums with Create, React app. So let's get rid of these Feyerabend. And instead, let's use the user event a weight. We have to use a wait event dot type. And we need the element so we can get it with good by rho dx box. And we're going to type the VDD. So the same thing. And now our test is passing agony. So whenever possible, use user bent over far band when using React testing library. And I know that user band doesn't include all the features of Feyerabend. But this is going to change. The future. User band is going to be upgraded and be more complete. So that's everything for this video. I hope you like it. See you in the next one. Bye-bye. 17. Testing a component in isolation with the user event API: Hi and welcome back. So today we're going to test a component in isolation. So we're going to do a unit test. Remember that in our app.js x, we have two components, so that's not ideal. We will like to have each component in one file only. So let's create a nother file, which is going to be custom input that TSX. And here we're going to copy and paste all of these block of code. We need react, import, React from React. And we also need to export default, these custom input functional component. And obviously here we need to import ok. Now we have these component in its own file. So it's going to also have its own testfile. Who's DM input that, test, that DSX. So sometimes you will test React components in isolation like this. Open these components don't have any side effects or states but only the input. So like this, we have only props. And well, the output which is a js X or a callback handler. And we have already seen how we can test DIA rendered DSX given a component. And perhaps now we will test a callback handler for these search component. And also we're going to see how the user event API is better or is more realistic than the far a bent API. So let's copy some things, some imports. Then we're going to delete the ones who are not using. And let's create our first best. Sweet. I'm going to say it when everything is okay. Let's add a test here. Shold call the on change callback handler. So remember, decent change callback handler is passed through the props. And we can market how? Well by saying dest dot Fn. And now the onchange callback handler is MLT. Now we have to render the component. So let's import the custom input. And here we're going to pass the Children, which is going to be input, for example. And we need to pass a value. We're going to pass an empty string and the unchanged handler, which is these unchanged MOC. Okay, now we're going to use the fire, sorry they user event API. And well first, let's see what happens with a Feyerabend. So let's import the Feyerabend. Let's get by role. Let's get that text box and give a target a value of David. Now, we can do some assertion over these mock. So we can say expected unchanged to have been called times one. So let's actually delete this app. I don't think we're going to use the smoke nor this user. And I don't think we're going to use a wait for, are going to use the Feyerabend, sorry the use or abandon. The next test. We're going to say show called The unchanged callback handler when using the buyer event function. So this is going to be our first test. And the onchange was called just once. So that's, I want you to, to see why this is weird. Because every time we write something with our keywords. For example, if we are typing that ID, then we should have typed five times. So the components have been re-rendered five times. Or D onChange, Callback handler, she'll have been called five times because we need five characters. And we're going to press in our keyboard five characters. But here we are. We're just calling the onchange handler once because the Feyerabend is just like copying all of these texts than it and pasting it there. It's like that. So now we're going to do the same test, but with the user event API. So she'll call the onchange callback handler. When using the user event. I'm API. Okay? So let's actually do the except exact same thing. So let's copy and paste. But instead of Feyerabend, let's use the user event, the type. And we'll again the screen you get by role are going to get the textbox and we're going to type David. Okay, so this should be async. Now because you serpent and he's a synchronous. And now our test is failing. Why? Because you can see that the received number of goals is 5, y five because we typed first the d, Then the a, then the V, then d, i, and d. So the onchange callback handler, she'll have been called five times. Now if I change this to five, the test is passing. So while the Feyerabend executes the change event by only calling the callback function once the user event triggers it for every key stroke. Well, anyway, this is a good test. But React testing library encourages to test React components not too much in isolation, but in integration. So remember that we talked about the integration tests. Well, react Justin library encourages more integration tests. Dan, unit tests like this. Because only this way you can actually test whether the state changes were applied in the DOM and whether side effects took effect. Okay, so that's everything for this video. I hope you like it and see you in the next one. Bye-bye. 18. Coverage: Hi and welcome back. So today we're going to learn about coverage. So for that, let's run john test minus-minus coverage. Again. Create React app has an issue with this because we have to specify also the watch mode to be false. So we need to do this. What all equal to false? And as you can see now we have the real courage. So for that, let's create a simple script which is going to be called coverage. And we're going to say jarring, best, minus-minus coverage, minus-minus watch o equal to false. Now we can simply run john coverage. And with that simple command now we can get the courage of our project. So as you can see that we have the coverage of 100% with AP and 100% with custom input. We didn't have a coverage of 100 births percent of getUser. And, but it doesn't matter because really these get user is like a MAC so we can't test it. In fact, let's do it, but this is not the way how we usually will test an API call like this. Because with an API call, we will have, for example, axis here. And we're going to actually make an example with anxious. And well, simply let's make a describe block here and say, when everything is OK, test should return a response. Ok, so what we will do here is to MLK, For example, if we were using axis, we will be mostly nexus. And just, for example, milking that get method the fractious and then confirming that this is returning some response. Ok? So for example, I can say cost, result. Oh, wait, get user. And I'm going to put a comment here. In a real project, you will use access and mark the get method, for example. But here, as we're not using axes and we are just resolving the premise. We can test the function directly and say expect result to equal ID1 and name Daddy. So that test is now passing. And we shall have 100% of coverage here. Okay? What else? You can see that here we have these index.js acts and Service Worker dot TSX. So well, the index.js X is heavily our entry file, so we don't need to test it. And the service worker Well, I don't know how to test this. I'm going to be 100% honest. I don't know if this can be tested. I think it can be tested, but I don't know how to do it. And in most of the projects I've worked on, we we are not testing these file, so we can ignore both of these files. And well, here comes another limitation of just, remember this, just config. We cannot extend the jest config from Create React app because great React app only lets us override some things from guest. Fortunately, we can overwrite these, collect coverage from okay, so remember I'm in the package.json not in adjust that conflict that JS, This is for our blogging just to work properly. And this is for taking out this index.js X and these service worker dot ts. So here we're going to specify that we want to collect coverage from everything inside source that ends with DS, DSX, JS, and J Sx. We want to exclude Service Worker dot ts. We also want to exclude the index.js x. Now let see what happens here. Now as you can see, we didn't have the service worker nor the index. But now we have this React app, EMF that D3.js. So that's a type. So we want to also exclude everything from source. That ends with the d dot ts. Okay, great. Now, as you can see, we have everything green and a global coverage of 100%. So that's very, very cool. Let's add this as a coverage script and get Bush, this code we just wrote. So remember, this is in the repo of this course, so you can see all of these in that repo. So I hope you liked this video. And as I told you, governor, which is very, very important, we can even configure in the package.json something called leaned, stage and Husky. And these, for example, will not allow you to push code if you don't have the necessary coverage threshold. So that's something that is configured in big projects. And well, you need to be very, very careful about the coverage. Okay, so I hope you liked this video. See you in the next one. Bye-bye. 19. Debugging: Hi and welcome back. Today we're going to learn something very, very useful, which is the bugging. So if you search the bugging in Google and click on the Create React tab page, then this is going to show you the instructions for debugging, both in Chrome, sorry, and also in Visual Studio code. So let's focus on Visual Studio code. Debugging just tests is done by adding these lunch dot JSON configuration file. So we need to add that lunch that JSON, but we're, well, let's create this Viscoat folder. And here let's create a lunch that JSON file. So now BS code is aware that it must take the configuration from there. Let's copy this thing here. And let's modify just the argument. So here it is saying, okay, so take reactive scripts, test running band. So running band means run the tests in sequence and not in parallel. No cash, watch all falls. And remember that we also need the EMF desktop environment. Just dump 16. Okay, now I think that babies okay, like that. And we need to add also this VS Code in the.gitignore I'm file. So I don't know why VS Code is showing here gray because, well, it's a a problem now with my BS code, but it is not hearing the gitignore. So just to make sure we are going to add also these to the gitignore because maybe other developers don't have B as quote, They may have, I don't know, Web Storm, which is a paid editor. So maybe this is not necessary for them. Not all people use Viscoat, although I recommend it because it's very, very cool. Okay, now we have that lunch dot JSON. Now we simply need to go to that test. We want to test. Okay, so let's go, for example to this get user_data test.txt. And let's put a breakpoint here. And now let's go to this depth here and start debugging. Now. As you can see, we stopped here. And here we have the variables. For example, I have the result which is an object of this type. We also have the debug console, which is very, very useful if I type result here, it's going to show me the same thing here. But now I can, I don't know. Say result, that ID equal to modify the result. And do very interesting things here. So that's everything I wanted to show you about debugging. You need to add these lunch that JSON configuration file, and then you are done. Let's simply stop this and say added VS Code to gitignore. By the way, I am going to modify this readme right now it's the default written it, but by the end of the course, I'm going to modify in order to have some interesting information that may help you with the course. Okay, so that's everything I hope you liked this video. See you in the next one. Bye-bye. 20. Creating a Pokemon component: Hi and welcome back. So we have learned a lot about that steam with React testing library. Now you have all the fundamental tools to test your React components in a real project. So now let's make yet another example. Are going to actually make an API call with axis. So let's add access to our project. So we're going to actually fetch the Bachman API. So are going to name our component. Welcome on that. T, S x. Fine. So are going to import React from React, are going to import axis from axis. And we're going to say bulk Amman API, URL. It's going to be HTTPS, bulky, api, dot CEO API. Version two. Now are going to create their functional component. We're going to say, give me the pocket moon name. Name, said the buck among name. It is going to be used as state, an empty string right now. And we're going to show the Pokemon abilities. So we're going to set welcome on abilities, which rag now is going to be an empty array. And finally, we are going to have an error. Error. Error is state. Right now it's going to be, no. Now are going to have an async function, which is going to be called handle fetch if you want the event. And we are going to see that type of disband later. So let's say let result and do it, try catch. So we're going to get an error. And in the try, we're going to say a result is going to be await axis dot get. And we're going to do then a string interpolation for common API URL. Actually, let's go to the Pokemon API. So you can see how this works. So you put the Pokemon API, so the URL we just set, and then you say pokemon and the name of the Pokemon. So in this case, d tau, we can say because u and we have all the information about bigotry. So we're going to say here a slash, Pokemon slash, the Pokemon name. Great. Now are going to set the pocket vulnerabilities. And for this, let's explore. This is what we are going to get this JSON. So let's copy and paste this here and say, but come on. Example, dot JSON. So we can have a reference of how the response is going to be. So it's going to be an object with this key abilities. That's what we're interested in. And this is going to be an array of this thing here. So let's open this side-by-side. And let's actually defining new type, which is going to be a ability. And this type is going to have a key ability, which is going to have a name, which is going to be string, URL, which is also going to be a string that is hidden property, which is going to be a Boolean, and slot, which is going to be a number. I don't know what this properties mean, but doesn't matter because we're not going to use them. Okay? So we can say here in the user state that this is going to be an array of abilities. Fine. This is going to restrain, this is going to be in there. Okay. Now, let's here put Pokemon abilities or salt dot data. And this is going to be a BLE, TIS. Perfect. Now in if we catch an error, we're going to say set Bachman abilities to an empty string and set error equal to the error that we catched. Okay, so this is the function that is going to handle our fetch. Now we need a function to handle the change. So event, we already saw that this is an event. This is a change event of an HTML input element. Ok? And this is going to simply set the Pokemon name to an event dot target dot value. Now we're going to return. So let's return a div. And inside this div, first, we're going to use our custom inputs or remember. This input is already tests. So the children were going to save Pachelbel name in the value. We're going to pass the buck common name, workable name. In the onchange. We're going to pass the handle change. Ok, so now we have a field to write our Bachman name. Now let's put a button here. The children of this button is going to be fetch Pachamama abilities. And this is going to be of type button. Unclick are going to handle the phage. Okay, great. So if the, if there is an error, we're going to say something went wrong. And three dots. Otherwise, we're going to in an unordered list, list all of the Pokemon abilities. So we're going to say buckle and abilities dot map ability. And here we're going to return a list element. Yeah, a list element. We a key. So the key can be the ability dot ability that name. So first, let see what is happening here. Can find name ability. So that's because we need an additional parenthesis here. What else? We need parenthesis here, okay, now it's working properly. So that's going to be the key. I think it's OK because the name is unique. We're going to have a link to the URL. So remember, this is the type of our ability. So we have gear ability that name and ability that URL. So ability that ability that URL. And finally here we're going to put the ability, that ability dot name. Ok, so now here the event, remember that we are, we are using this function in this onClick from this button. So the event is going to be a mouse event. Okay? And we need to export default, export default. Welcome. Okay, so now our, I think our component is working. So here in the index, let's render instead of app, let's render popular. And let's get rid of this app. And that's darn start this thing. Okay, so buckled name. Let's put here. I don't know. Let's put the data like in the come on example. So did the has the stabilities, limber and impostor. Let's be G2, static and lignin rot. What else? Charlie's art. He has blase and solar power. So it looks like our component is working fine. Now the next step that we're going to do in the next video is to actually test this thing. Okay, so I hope you liked this video and see you in the next one. Bye-bye. 21. Testing the Pokemon component: Hi and welcome back. So last time we created our procurement component here in React. But I forgot to test am when something went wrong. So for example, if I put something that does not exist, then this is throwing something went wrong. So that's something that we also need to test. Let's first see what's the coverage of our project. So you can see everything is 100% except Buckman's because, well, obviously we didn't have any tests yet for that. So let's create a new test, but come on that test TSX. And here we are going are going to define our test. So when the user enters a valid name, well, we have to say what is the test should show the bug human abilities of that backbone of that package. Okay, fine. Now let's here, put the test as an async because we have something that is synchronous, which is the axis, get a request. So here we're going to say abilities. The lettuce is going to be equal to an array. And here in the array we're going to have, well, let's remember. Let's go to her Pokemon and see the type of the ability. Ok, so it's going to have an ability which has a name. Hmm. I don't know. You can name it whatever you want. I'm going to save testability 100. Remember the abilities of these things? And I'm going to say, we'll dot com ability T1. I don't know whatever you want. So I'm going to say bility.com dot last turbidity one. And if you want you can include also those is hidden and slot properties. But I'm not going to do it unless type script somehow complaints about that. And I'm going to say, I'm going to include another ability which is going to be testability to and the URL is going to be the same. But with the ability to. Okay, fine, so now we have our abilities. Now we have two MLK axis because remember we don't want to heat the API. So let's. Board axis, axis, and let's say just mock axis. And now we are using that script, so we have to do something else. We have to say mod axis, say axions, S, just dot mocked, and the type of type of acts. So that's how we're going to mug axis. And we are going to say mock, mocked axis. And now we have all of the properties from the MAC. And we want to say get mock resolved value once. And here we are going to resolve data abilities. We already have a villages here, so that's fine. Now we are going to render. So that's going to be important for our testing library react. And we want to render our Pokemon app component. Are Pokemon components, sorry. And well, what else do we need? Showing here an error, reactors not defined, we need to react. So import, React from React. And now let's await and use the user event a, BI and type. And we need the screen and get by rho. So remember, what do we have here? Again, that one are going to get the text box and we're going to type and I don't know detail or whatever you want. Okay, so we need to also import screen. It's still get by role. Okay? Now we typed Ditto. And we need to also click the button. So we're going to say click. And then we're going to say screen also get by role. And the role has, the button has a roll of bottom. And now we're going to say const returned her. No, you can say, you can name these return abilities if you want. Return abilities. Away the screen. Find all by, by row, list item. So as you can see here, it is already given me this int list item is going to, is going to be the role of each of these things here. We're going to expect the returned abilities to have length of two, because we are having two of these things here. Great. So our test passes. Now let us see again what is the coverage of our test. So it's almost Green everything, but here in the brand we have 50%. The branch refers that we are not covering something, which is line 2728. So this is going to also render conditionally this part here, which is something went wrong. So we need to also have a test for this case. Or we're going to have, we're not going to have a coverage of 100%. So now let's make another test suite and say when the user enters and invalid by common name, should show an error message in the screen. Fine, so we're going to actually copy and paste this and then modify some things. Again. So Abilities, we're not going to return any abilities. And now we are going to use mock rejected value once. And here we are going to simply reject with this value of a new error. Then we're going to render the Pokemon component. We're going to put something valid welcoming name. And here we are going to click on the bottom. So this is going to be the same. And now we're going to say counts to mess, which are going to weight these fine by text and say something went wrong. And now we're going to expect our message to be in the document. Fine. Now, our test is passing because the message something went wrong appeared in the document. Now let's see what's the coverage? Now it's 100% and you shall be happy with that because we're having 100% courage. That's fine. So we have tested this component, which makes a real API call to this Pokemon API URL. And we have made a test that does not make an API call, but simulates, um, or mud that get request. So that's very, very cool. Let's actually put this at it. The test for the component, for the Pokemon component. And now this is very, very well-tested. So I hope you liked this video. I'm very happy about this and see you in the next one. Bye-bye. 22. More custom matchers: Hi and welcome back. So just for the sake of completeness, I wanted to show you these library which is also from React Destin library, that's called Destin diary, just dump. So as you can see, these gives us more matchers, more of these custom matchers, for example, to be disabled, to test. For example, if a button is disabled or not, or not to desktop, if the button is enabled or not. To be empty to being the document which is also just already in React test in library. To contain element, to contain HTML, to have focus for him, for example. And all of these are very useful when we are working in the front end. Ok, so that's very easy to install. They give you the instructions here darn at as a deaf dependency testing library, just dumb. And you can import testing, never just dumb. And you're going to have all of these custom matchers. So I just wanted to show you that you can install this to have more custom matchers. And this is from testing library. Okay, that's everything I wanted to show you. So you in the next video, bye bye. 23. Bonus: one of the coolest tools in software development: Hi and welcome back. So today I'm going to show you one of the most useful tools in software development. And I'm not exaggerating. This tool is very, very useful. So if you search for a SDF in Google, the first result is going to be these SDF movie having watched that. But let's ignore it. And let's go to the second result, which is this github ripple. Lets read the readme AS GF. Manage multiple runtime versions with a single CLI tool extendable via plugins. As df is a CLI tool that can manage multiple language runtime versions on a per project basis. It is like JVM, which is go lung Version Manager, and VM, which is Node Version Manager, RBM, which is basically the same but for rubbing and by emf, which is the same but for Python and more all in one. Simply install your languages plugging. Why use a SDF? It's a single CLI for multiple languages. Very cool, consistent commands to manage older languages. Single global config, keeping the faults in one place. Single No.2 versions config file per project. Support for existing config files like Node Version dot m v m, r. Seem that Robbie version, that Python version, et cetera, for ISI, migration automatically switches runtime versions as you traverse your directories. Simple plug-in system to add support for your language of choice, are going to see that it's really that simple shell completion available for common shells, bash Z, ASH, which I'm using fish, etcetera. And also it has a great, great documentation. So let's click on here and getting started. And here we have the install process. As you can see, you can select your operating system in this drop-down here. And you have to note that windows is not here. We only have this tool for Linux and Mac OS, but you have Windows subsystem for Linux or WSDL. So I hope that it works. Also. These commands only for installing Carlin Get. You may have already installed this if not installed them AS df installation method and get the swarmed just clone disruptors repository to these that ASD F folder or directory. These branch version 0.8, at the time I'm recording this video alternative. Well, you didn't need to do that. If you successfully cloned this ripple, as stated here, then you have to add something to your shell. If you're using Linux, and my case I'm using z as h. So I just have to add the following to the as HRC file. And Yeah, well, I'm going to show you that I have these command set in the sea as HRC. So if I go where I said, I can see this. Let me just get this. Ok, so I don't know why it didn't show him in the editor, but here it is showing that you're gonna seem that hom ASD if ASD f, sorry, slash ASD, F dot SH. So yeah, you just have to add this thing to your CSA TRC if you're using COSH or if you're using bash to your bash, bash RC. And if you're using Mac OS, Well the same but to your.bash_profile or again to your zs HRC. So that's basically the installation process. If you want to update this tool, it's extremely easy. A SDF update, and that's all. And if you want to remove it, Well, do you have here the commands, but don't remove it because it's vertical. Okay, So as you can see, the installation process is easier. And now let's go to the Manage plugins, which is what we want. So basically you can add plugins. So first, let's see all of the plug-ins. So I think it's plugging list all. So as you can see, we have lots of plugins. We have these things. I don't know what this thing is. We have a Clojure. Let me see. Dino. We elixir Elastic Surge.net or go blank. Github CLI, so that's cool because it's very variations. We have G-Cloud. What else? We have? Well, we have lots of things here. You can check it out for yourselves. If I type a SDF lugging, this, you can see that I have goaling NodeJS and buy them. If I want to see what Python versions I have, I think it's like this AS df list by them. So I have 3.8.63.9. Let me see if I can see the current version of Python. Yeah, I have the current version of Python which is 3.8.6. I'm using this. If you want to add the blogging. So yeah, I skip that part. But if you want to add a plugin, just say plugging at Batson for example. And well, it says here that I already have Python installed. But you're going to add that plugging without any problem if you run this command. Okay, now let's go to this part of the documentation managed versions as df install, the name of the programming language basically and the version. We can also see the list of all the versions. So ASD f least old by them. And as you can see, we have plenty of things here. If we go to the top, we have all the Python versions from 2.1.3 to three-point ten. Dash deaf. So it's right now in deaf mode. Okay. So that's how you install lads installs something that me grep sunk a 3.7, I guess I have 3.7.9. I'm going to stall that. He SDF install Python 3.7.9. And it's going to take its time because it has to download the Python version from, from this page. And that's fine. Okay, so that's very cool. Let's wait for this to finish. But in the meantime, let's remember that I have current version of Python 3.8.6. Now suppose I want change to my, to my system version of Python. So here are the commands, a SDF global, the programming language name, and the version you can use System with my emf. So global Python system. And as you can see, now I have Python version 3.8.5, which is my system Python version. So let's switch back. Well, actually let's see if it is not ready yet. But let's switch again to my iPhone version 3.8.6. And if I say python dash capital V, I have python 3.8.6. I think this is going to take its time. So don't worry. I'm not going to worry about that. Now let's go to the SPR project and let's run this command, a SDF local buy 3M. And I'm going to say 3.9. As you can see. Now we have the dot tool versions, which is specifying, hey, for this project, use Python 3.9. So very cool. Well, the installation for Python 3.7.9, he's done. So let's run a SDF global, Python 3.7.9 and say python minus v, It's going to be 3.7.9. And here, let's execute by 3m minus B. Sorry that capital V, 3.9 points here. So very cool. We have a global Python of 3.7.9. But here I have a local version of Python 3.9. So that's a great goal because, you know, buy them through 0.9 at the time I'm recording this video is very, very new. So if you are working we, these version of Python, you may have breaking changes. Ok, so as you can see, these also works for not only python, but no DES for example. So for that, let's run ASD f Plugging list. And as you can see, I have no dare so a SDF least NodeJS. And I have these two versions, 10.15.3 because, well, right now I am working on a project that uses this version by them. And I can see the current version of node.js is these one because that's all you. I'm working on a project that uses dispersion, but it's the same. You can global NodeJS 12.18.4 and node minus B. Sorry, note, minus the 12.18.4, that switch back to version 10.15.3. And now we have this version of note. So as you can see, this is a very, very cool because you can manage all of your programming languages, all of the versions with a single CLI tool. And that's why I said that this is one of the most useful tools in software development. So I hope you liked this video. You learned a lot and see you in the next one. Bye-bye.