Introduction to Testing: Concepts for Beginners - React.js Testing Tutorial #1

hello youtube my name is bruno and today i'm very happy to welcome you to this react testing series during this series you will learn all the tools and techniques you need in order to create good unit and integration tests for your react applications there are a few tools that we will use across all the videos in this series they are just react testing library and typescript if you know me you know that i will also reserve two or three videos at the end of this series just for next js testing where we are going to test get server side props get static props and connect it to a database now in the first videos i will take the assumption that you are starting your testing journey so you have never done a test in your life and taking that into account i will take this video's opportunity to answer the four or five questions i receive the most from people in your position and the first of those four or five questions is regarding this testing list that i have over here what's the difference between end-to-end testing integration testing and unit testing and even when to use those so let's start by the top one end-to-end testing because i will say it's the easiest one to explain and at the same time the one that everybody agrees on the explanation let's say that in your company you have a manual tester with some list of tasks that they need to do before you deploy to production so they will click in the login button they will put some passwords they will see the login working that task is with a check so you can test the next task but is a person doing that and that's slow so an end-to-end test is just automating this type of job with tools like selenium or cyprus regarding integration testing is when we test two or more units which leaves us with the question of bruno so then what's a unit well if you are coming from object oriented programming usually a unit for you in that world is a class in the case of react components we can say it's a component but not everybody will agree with that distinction so i usually like what can see dot once said in his blog and you should follow his blog he said that he really doesn't care about the distinctions what is an integration test or an end-to-end test what he cares is the value that it's providing to the business that you can catch bugs and at the same time every time that you are doing a breaking change your test will fail because that's what the tests are there for to catch the bugs that we create in our code and also allows us to do refactoring of our code that's what can see dots wants that's also what i usually like to have but i will give you a real world example completely unrelated with code just to show you that different teams can have completely different abstraction levels and call something a unit test and another team an end-to-end test and both be right let's say that now you are working for a car company and you are in the assembly line receiving the engine from another team and fitting the engine into the car receiving the seats from another team and putting the seats in the car you receive the steering wheel and your team sees every single of those pieces as a unit so after a while you start to notice that the engines that you put in the cars sometimes they don't work so you come up with the idea of creating a unit test to turn on the engine and turn off the engine before you assemble the engine in the car you go to your cfo and you say look we are saving like four hours because every time that now the engine is broken we don't need to remove the broken engine and put a new good engine inside the car that can also be broken that engine so with this alone we save let's say four hours every time that happens your cfo loves that idea and tells you to go to the engine department and explain what you did you arrive at the engine department and you say hey look i did an amazing unit test for your engine i'm turning on and off the engine and everybody in that team will hate you at that second because they will ask you hey do you even know how an engine works it's not a unit test what you are doing is an end-to-end test and they will tell you look we in order for an engine to work we need to have the pistons that go inside the cylinders that alone is already an integration test and then you have a thousand more pieces in order for the engine to turn on and off so what you are doing is an end-to-end test and now you might ask me bruno so which of those two teams is correct well in reality they are both correct they are just working in completely different levels of abstraction that's why i love dad from kent c dodds that you just stop referring what is the test type because if you go to the engine department and you say oh i created a new test and that test is to turn on and off the engine and put the engine in the car everybody across your company will agree with that test i usually never name the type of tests i just care about the value and the safety that that test is giving me like cancer it says the confidence the test gives you now another question that i receive a lot is regarding what is mocking i read mocking everywhere bruno why is that even useful let me give you the same example with the car company let's say that in order for you to turn on and off the engine you need some kind of power which will come from the battery but usually you can't fit the battery in the cars immediately because if the car is in storage for let's say one year that but battery will no longer work so usually what factories do is they test it with something that they connect directly to a power wallet so the test that they are doing doesn't rely on the battery because the battery can even be already dead at that moment so you are really just testing your engine and that's what mocking means you remove one part of your code and you replace that by something that is safer and at the same time is more reliable it's much more reliable for you to connect your engine to a power outlet than connecting it to a battery that has different levels of quality right so you just want to test the the engine you don't care about the battery in this test you mock the battery by something else then the third and the fourth question are actually kind of the same thing which is when should you test something and why should you test that something and usually you will see people coming up with a priority chart with a risk of that chart and everything that is high priority and high probability you should create tests for it there is no way around that if you are lucky enough that your company allows you to have 100 code coverage and allows you to have everything then you can ignore this section because this section is not for you but some companies especially startups you don't have the time to test every single component that you produce so usually what i will say is ask yourself if this bug happens is this very dramatic for my company can it put my company at risk if yes test it if it's something that you say no if it happens nobody really cares don't test it i will give you an example let's say that you are in amazon and let's say that amazon for whatever reason allowed you to change your profile picture is that an important feature if it stops working no actually today amazon i don't think they even have a profile picture so if it fails it's not a huge deal but if the credit card is not working and that flow is not working is very dramatic for amazon because it's where they make revenue so you should 100 percent test that with both integration and even end-to-end tests in that in that scenario right so usually what i test i always ask this question is this something that will happen quite a lot of times and is annoying enough to damage the reputation of my company fix is this something that even if that thing only has a one in a million chances of happening it can destroy my company immediately i will do that test everything that is in this corner over here not important and not too dramatic if it happens i usually will say you are quite okay to not test it of course if you have the time test everything in your application that will be the ideal scenario one very common question i hear is regarding this pyramid of testing and if you went to university your teachers were all the time bombarding you with this one telling you that you should do a lot of in unit testing a bit less integration and even less end-to-end testing and why is that well if you take again the example of the car and the battery you know that if you have a lot of pieces working together in your end-to-end tests it will be harder to not have some variability there so your tests may become a bit flaky when a third party api doesn't respond or something like that that's why usually people start to mock a lot of stuff going down to the unit testing level now a lot of people myself included i don't like that i prefer something more like that and i will give you some people online that you probably know that agree with me or some of them looking at the date of the tweet probably i agree with them because they said it before me so guillermo the ceo of vercell creators of nextjs said the following write tests not too many mostly integration and immediately after one of the creators of css modules said i'm assuming anyone who disagrees with this as it attempted a significant refactoring a code base with too many unit tests in less than a minute i will give you one example that happened to me and you will understand this much better but i will just read something from dan abramov the creator or one of the creators of redux and he is currently working for facebook in the react core team and he said the following a suite of integration tests written at the right level of abstraction is chef's keys right you need to find the level that's just below where the flakiness occurs so i already explained what flakiness is then it's much more useful than individual unit tests you have someone else can see dodge once again saying the following if you have to delete your tests after refactoring then what good did they do to you this is what tests should be like now i think i'm in a right mood to explain what happened to me in that situation so i was building an application with one of my best friends and the way we were testing our http calls was to mock axios and we were doing that just.mock i will show you in a few videos how you do that so don't worry too much but we were mocking axes and when we decided to move to fetch all our unit tests they were completely broken because now all our tests were expecting access to have been called and axios was not being called when we moved to fetch because we were testing an implementation detail in video i think is six or seven of this series i will explain how you can test without having to mock axe use or fetch so in the future if there is a new browser feature to replace fetch you can just use that browser feature and your test will help you in that refactoring that's what they meant is your test should help you with your refactoring if your users are still seeing roughly the same thing or exactly the same thing in this case your test shouldn't break it's very frustrating when you go to an application you change something the behavior for the user is exactly the same and then you have 10 tests that are failing right now because they are mocking something or expecting something which is an implementation detail so usually what i say and this is probably the best advice of all the series is when you are testing test the public interfaces or the public api of your components if your components receive four or five parameters pass those four or five parameters and just test what html your component is returning don't test or at least avoid testing internal components and mocking those internal components because otherwise when you want to refactor it will become a very big point for you now in the second video i will show you how you can configure your application in order to have testing with dsgs typescript next.js react and all the good things that you might want for all the videos that we will use so that will be the base of all the videos and that video is over here is number two if you already know how to do that and you prefer to go to video number three it will be here and over here at the top it will be the full playlist so if you click there you will see all the videos that exist in the playlist and just watch the ones that you care about so i really hope you enjoyed this one i hope you also enjoyed the next one and i see you very very soon bye

Channel: Bruno Antunes

Views: 3,199

Keywords: introduction to testing, testing for beginners, react.js testing for beginners, pyramid of testing, unit-testing react, unit testing react, unit testing react.js, react.js testing, automated tests, react-testing-library, jest, next.js unit testing, testing nextjs, unit tests next js, integration testing react, integration testing react.js

Id: 41ox41v62jU

Length: 12min 28sec (748 seconds)

Published: Wed Jul 14 2021