1 00:00:02,280 --> 00:00:06,110 Now what is testing and why would we want to test ? Now 2 00:00:06,120 --> 00:00:10,680 testing, when you hear it for the first time, sounds pretty obvious, pretty straightforward. 3 00:00:10,680 --> 00:00:14,820 We are writing an app, we're creating an application and we simply test it, right, 4 00:00:14,850 --> 00:00:15,850 we had a feature, 5 00:00:15,930 --> 00:00:21,990 we opened the browser and we test our application and that is indeed how you will continue to work even 6 00:00:21,990 --> 00:00:25,680 if you do add this kind of testing I'll dive in in this video. 7 00:00:25,680 --> 00:00:29,150 So testing manually still is something that makes sense, 8 00:00:29,160 --> 00:00:31,500 you want to see your application run. 9 00:00:31,500 --> 00:00:36,100 So in the end, the idea always is that we have our code and we have some expected result, 10 00:00:36,120 --> 00:00:42,720 so if we write some code and then we go into the browser and test this code we have some idea of what 11 00:00:42,720 --> 00:00:43,640 should happen, 12 00:00:43,710 --> 00:00:49,560 we want to open that modal, we want to add that user when we click that button, something like this. 13 00:00:49,560 --> 00:00:55,800 So we have our expected results in mind and then we simply test our application and if we are successful, 14 00:00:55,800 --> 00:00:57,300 we are fine with that, 15 00:00:57,300 --> 00:01:02,520 we can continue with writing the next piece of code and if we're not happy with the result, well then 16 00:01:02,520 --> 00:01:09,000 we can modify our code and fix the issue or adjust it such that it works in the way we want. 17 00:01:09,000 --> 00:01:16,230 Now the idea of Javascript testing or code testing when you read it like this is that we automate this 18 00:01:16,230 --> 00:01:23,310 testing part, so that we automate it so that we don't have to manually test everything in our application. 19 00:01:23,310 --> 00:01:30,270 Now we will probably still test everything manually but automated tests can be run whenever we change 20 00:01:30,270 --> 00:01:36,210 something in code to see if that affects any part of our application without us having to test everything 21 00:01:36,210 --> 00:01:37,370 manually again, 22 00:01:37,380 --> 00:01:45,150 that's the idea behind automated testing, that we can see breaking changes or issues in our code, maybe 23 00:01:45,330 --> 00:01:51,410 introduced by a change in place A in a totally different place of our app, that we can see this instantly, 24 00:01:51,420 --> 00:01:55,110 That is one of the major benefits of writing tests. 25 00:01:55,110 --> 00:01:58,560 So that is also one answer to the question, why would we want to test? 26 00:01:58,560 --> 00:02:04,650 We want to get an error and see the error if we break our code, we want to see that immediately without us testing 27 00:02:04,650 --> 00:02:05,650 everything manually, 28 00:02:05,730 --> 00:02:13,140 we might still do manual testing but it's still worth a lot to have a suite of predefined automated tests 29 00:02:13,350 --> 00:02:15,480 that we can run to quickly see 30 00:02:15,480 --> 00:02:17,670 did this change break anything, 31 00:02:17,670 --> 00:02:21,500 well with well written tests, we'll get the answer right away. 32 00:02:21,540 --> 00:02:25,840 We'll also save time if we don't have to test everything manually over and over again 33 00:02:25,980 --> 00:02:31,680 and we are also forced to think about possible issues or bugs when writing our tests. 34 00:02:31,680 --> 00:02:34,600 We have to think about what do we want to test, 35 00:02:34,650 --> 00:02:38,160 how do we write a test that makes sense 36 00:02:38,160 --> 00:02:44,070 and I'll dive into that and this video already. We also can integrate it into our build workflow, 37 00:02:44,070 --> 00:02:49,920 this is something more advanced but there I mean that you could have a build workflow where you push 38 00:02:49,920 --> 00:02:57,210 a commit, so a git commit to your code repository like Github and then you have a workflow that automatically 39 00:02:57,210 --> 00:03:03,090 is triggered where this code is then tested in the cloud on some server and if the test succeeds, it's 40 00:03:03,090 --> 00:03:08,670 maybe deployed automatically. So you can build a very complex deployment chain there and tests are then 41 00:03:08,670 --> 00:03:13,780 an integral part of ensuring that no breaking or invalid code is deployed, 42 00:03:13,800 --> 00:03:20,670 so that is always an advantage of tests or something you can use tests for. We can also break up complex 43 00:03:20,670 --> 00:03:23,730 dependencies and that is also something I'll show in this video, 44 00:03:23,730 --> 00:03:29,730 we have to make sure we write code that can be split up, that is modular because this will make testing 45 00:03:29,730 --> 00:03:35,550 easier and ultimately it will make working with our code easier and it improves our code 46 00:03:35,550 --> 00:03:42,540 therefore since we are forced to follow certain patterns or to write code in a certain way or at least 47 00:03:42,570 --> 00:03:47,310 that will make testing easier, we will write better code all together. 48 00:03:47,340 --> 00:03:53,190 So these are a lot of great advantages but they might still be a bit abstract when you have not written 49 00:03:53,190 --> 00:03:54,210 any tests, 50 00:03:54,210 --> 00:04:00,810 so let's dive into testing soon but not before I try to answer one other question and that is, which 51 00:04:00,810 --> 00:04:02,460 types of tests do we have? 52 00:04:02,820 --> 00:04:09,690 I'm talking about automated tests, so some code we write that tests our code, so code that tests code, 53 00:04:09,720 --> 00:04:14,640 that is a good description of what testing is or what automated testing is I guess 54 00:04:14,640 --> 00:04:16,650 and there we have different kinds of tests. 55 00:04:16,710 --> 00:04:21,090 We have some tests that test a fully isolated piece of code, 56 00:04:21,090 --> 00:04:25,530 let's say a function that takes some input and returns some output. 57 00:04:25,650 --> 00:04:31,740 We can test such a function with a test because it has a clearly defined structure and we can say for 58 00:04:31,890 --> 00:04:35,510 input x and y, we expect to get output z 59 00:04:35,670 --> 00:04:43,200 and that would be a so-called unit test because we test a single, isolated unit of our application. 60 00:04:43,200 --> 00:04:48,540 We also have some tests that test units with some dependencies, 61 00:04:48,540 --> 00:04:54,480 so we have no isolated piece of code anymore but we might have a function that calls another function 62 00:04:54,480 --> 00:04:55,230 let's say 63 00:04:55,230 --> 00:05:00,750 and therefore the function we're testing depends on the result of another function and that is called 64 00:05:00,750 --> 00:05:05,100 an integration test because there, we're testing more than just a single unit, 65 00:05:05,100 --> 00:05:11,400 we test the integration of a feature into another features so to say. We also have the full flow 66 00:05:11,400 --> 00:05:14,010 which we can test or the user interface, 67 00:05:14,040 --> 00:05:17,750 so the full application or a part of the full application 68 00:05:17,910 --> 00:05:21,750 and this is so-called end-to-end or also user interface test. 69 00:05:21,780 --> 00:05:27,360 The idea here is really that we do what we could do manually as well in the browser but that we write 70 00:05:27,360 --> 00:05:32,790 kind of an automated script that executes a certain series of steps for us and then we can check if 71 00:05:32,790 --> 00:05:36,010 the result is the result we expected to get. 72 00:05:36,120 --> 00:05:42,030 Now these kinds of tests have a different complexity, units tests are relatively easy to write because 73 00:05:42,030 --> 00:05:48,750 you have a small unit and you know it is easy to infer what you want to get as a result. 74 00:05:48,750 --> 00:05:54,330 The more dependencies you add, the more complex it becomes because it gets harder to differentiate between 75 00:05:54,600 --> 00:06:00,600 what exactly is causing an error, is it a dependency or the function that uses the dependencies. 76 00:06:00,660 --> 00:06:06,150 Also you might have some dependencies that reach out to a server and fetch data, that is also complexity 77 00:06:06,150 --> 00:06:12,420 you have to handle and I will show you how to handle this in a separate video. And the full user interface 78 00:06:12,420 --> 00:06:17,640 test is the most complex one because there, you have to define every step that should be executed and 79 00:06:17,640 --> 00:06:22,090 cleverly think about what you want to test and what you want to expect there. 80 00:06:22,110 --> 00:06:27,620 Now also due to this complexity, we write tests in a different frequency. 81 00:06:27,660 --> 00:06:33,120 We typically have a lot of unit tests because if you test every unit of your application and it works 82 00:06:33,120 --> 00:06:38,180 correctly, you can kind of infer that the overall application will also work correctly, 83 00:06:38,250 --> 00:06:40,220 so we will have a lot of unit tests. 84 00:06:40,290 --> 00:06:47,380 We then have some integration tests to rule out that two individually working units don't work anymore 85 00:06:47,400 --> 00:06:56,730 if you combine them and we have a few UI or end-to-end tests, to test some steps or some flows in our application 86 00:06:56,940 --> 00:06:59,370 in the browser, in an automated way. 87 00:06:59,400 --> 00:07:00,910 So these are the kinds of tests 88 00:07:00,930 --> 00:07:03,810 and in this video I will show you all three already 89 00:07:03,810 --> 00:07:05,690 and with that I'd say it's enough of the theory, 90 00:07:05,940 --> 00:07:07,380 let's start writing some tests.