1
00:00:00,210 --> 00:00:07,220
In this lesson you'll be kicking off our section on node j s testing by doing two very important things.

2
00:00:07,230 --> 00:00:13,350
First up you'll be creating and running your very first test so you'll see exactly what tools we'll

3
00:00:13,350 --> 00:00:15,360
be using to get that done.

4
00:00:15,390 --> 00:00:22,350
Then the second thing you're going to do is take a few minutes to explore why testing code is so essential

5
00:00:22,590 --> 00:00:29,240
whether it's a no J Yes application or an application written in another programming language.

6
00:00:29,280 --> 00:00:36,600
You should be writing test cases to automatically verify that your project is always working as expected.

7
00:00:36,600 --> 00:00:39,300
Now that order might seem a bit counterintuitive.

8
00:00:39,330 --> 00:00:45,050
You might want to know why you should test your code before you actually write your first test.

9
00:00:45,090 --> 00:00:51,420
But I promise it's gonna be a lot easier to understand why you should test code after having already

10
00:00:51,420 --> 00:00:53,430
written a test case.

11
00:00:53,430 --> 00:00:55,280
So that's the order we're going to take.

12
00:00:55,380 --> 00:00:59,640
We'll write a test case then we'll talk about why tests are so important.

13
00:00:59,700 --> 00:01:06,200
And by the end you'll be ready to continue on and start to write tests for the task manager app.

14
00:01:06,210 --> 00:01:08,870
All right let's go ahead and dive right in.

15
00:01:08,940 --> 00:01:13,950
By setting up the one tool we're going to need to write our test cases.

16
00:01:13,950 --> 00:01:19,410
Now there are literally dozens of different libraries that allow you to create and run tests for your

17
00:01:19,410 --> 00:01:19,810
notes.

18
00:01:19,810 --> 00:01:22,740
J asked application over in the browser.

19
00:01:22,740 --> 00:01:28,310
We're going to explore two of the major players one of which we'll be using in this section.

20
00:01:28,470 --> 00:01:30,430
So let's crack open two tabs.

21
00:01:30,470 --> 00:01:38,710
The first tab is going to open up the just testing framework which we can find at just j s dot I O.

22
00:01:38,730 --> 00:01:43,340
Now this is the testing framework we're actually going to use in this section.

23
00:01:43,510 --> 00:01:48,510
The other testing framework which I want to take a quick moment to address is Moka.

24
00:01:48,570 --> 00:01:52,530
You can find that over at mocha J S dot org.

25
00:01:52,590 --> 00:01:58,480
Out of all of the options available to you as someone who wants to write test cases for their note J

26
00:01:58,510 --> 00:02:06,120
asked project I'd say that Moka and jest are definitely the most popular and the most widely used.

27
00:02:06,380 --> 00:02:11,820
Now as you head out into the real world and start to work on Node projects whether they're open source

28
00:02:11,820 --> 00:02:16,570
or for a company you'll see some companies that happily use Moka.

29
00:02:16,710 --> 00:02:24,630
Other companies that happily use Gest and other companies still that use other testing frameworks entirely.

30
00:02:24,630 --> 00:02:27,450
All of these can achieve all of these same results.

31
00:02:27,450 --> 00:02:33,210
So in the end of the day it's really just a matter of picking one that fits your personal style and

32
00:02:33,240 --> 00:02:37,650
preference and then starting the process of writing your tests.

33
00:02:37,770 --> 00:02:42,090
And the good news is that it's pretty easy to switch between them should you need to.

34
00:02:42,270 --> 00:02:45,340
But once again they can all do the same stuff.

35
00:02:45,360 --> 00:02:50,820
So what we're going to do is go with jest just as a bit more modern and comes with a couple of nice

36
00:02:50,820 --> 00:02:56,330
to have features that just make it a little easier to write and manage our test cases.

37
00:02:56,340 --> 00:03:03,810
So what I'd like to take the next few minutes to do is set up just in our task manager project and create

38
00:03:03,840 --> 00:03:12,060
and run our very first just test over in Visual Studio code the very first thing we need to do is install

39
00:03:12,060 --> 00:03:19,470
a brand new NPM module so something new as a development dependency to all of the modules for testing

40
00:03:19,470 --> 00:03:23,890
our application are only going to run on our local development machine.

41
00:03:23,910 --> 00:03:29,760
They're not things we're going to need on our production server so we can install them as Dev dependencies

42
00:03:30,210 --> 00:03:33,090
right here from the task manager directory.

43
00:03:33,090 --> 00:03:41,490
We're going to install just using the following command that is NPM I jest at twenty three point six

44
00:03:41,580 --> 00:03:42,900
point zero.

45
00:03:42,900 --> 00:03:49,150
Then we'll specify that save Dev flag to save jest as a development dependency.

46
00:03:49,230 --> 00:03:55,920
I'm going to take a quick moment to run that and once it is done all we need to do is setup a single

47
00:03:55,950 --> 00:04:04,380
new script that script is going to start up just and just is a zero configuration testing framework.

48
00:04:04,470 --> 00:04:08,840
That means that by default it has everything in place for us to get started.

49
00:04:08,910 --> 00:04:15,510
But of course there are options and arguments we can use to customize it as we want to change how just

50
00:04:15,510 --> 00:04:22,290
works and we'll explore some of those a bit later but for now Gest is installed and well we're going

51
00:04:22,290 --> 00:04:26,670
to do is create a new script in our scripts object.

52
00:04:26,700 --> 00:04:31,350
This script is going to be a key value pair like our other ones.

53
00:04:31,410 --> 00:04:35,730
The name of the script will be test and what are we going to do.

54
00:04:35,940 --> 00:04:40,130
We're gonna use gest that is just and we're done.

55
00:04:40,140 --> 00:04:44,330
There is no need to provide any additional details.

56
00:04:44,370 --> 00:04:49,860
So right here when we install jest we get access to it as a command we can execute.

57
00:04:49,920 --> 00:04:55,620
We could install just globally to run it from the terminal but since we've installed it in our project

58
00:04:55,650 --> 00:05:01,540
like we've did with things like node man we can simply access it from our drifts up above.

59
00:05:01,540 --> 00:05:07,030
Now that we have this in place what I want to do is actually run the test command just to see what we

60
00:05:07,030 --> 00:05:07,710
get.

61
00:05:07,870 --> 00:05:12,600
So from the terminal I'll be using clear to clear the terminal output.

62
00:05:12,640 --> 00:05:16,170
Then I'll go ahead and run NPM test.

63
00:05:16,240 --> 00:05:21,130
I'm gonna fire off the command it is going to start up just and what do we get.

64
00:05:21,130 --> 00:05:25,120
Right here we can see we have an error the error message.

65
00:05:25,120 --> 00:05:29,770
No tests found it's telling us that it's looked in our project.

66
00:05:29,770 --> 00:05:37,210
The task manager directory and it's checked 10 files for test cases but it hasn't been able to find

67
00:05:37,300 --> 00:05:38,980
any test files.

68
00:05:39,010 --> 00:05:45,880
So what we're going to do is create our very first file to house our very first test.

69
00:05:45,910 --> 00:05:50,750
The first thing we want to do is create a new folder for all of our test cases.

70
00:05:50,770 --> 00:05:54,250
So that's gonna be a new directory in the root of our project.

71
00:05:54,280 --> 00:05:59,980
So a new folder in the task manager directory which I will call tests.

72
00:05:59,980 --> 00:06:02,520
Now that name is not particularly important.

73
00:06:02,530 --> 00:06:07,090
You could call it whatever you like but the name it tests is pretty clear.

74
00:06:07,090 --> 00:06:12,790
Next up we'll be creating a file to contain some test cases as we write more tests.

75
00:06:12,790 --> 00:06:15,710
We will break them up across multiple files.

76
00:06:15,820 --> 00:06:19,160
But for the moment we can just start with a single one.

77
00:06:19,510 --> 00:06:25,600
Now right here let's say we're trying to write some tests to make sure some math functions we've created

78
00:06:25,810 --> 00:06:34,810
are working as expected I might call the file something like math dot test dot J S in here we'll write

79
00:06:34,840 --> 00:06:38,820
our test cases and this file will be picked up by jest.

80
00:06:38,890 --> 00:06:45,220
The reason Gest is going to treat this file as a file that contains a test cases has to do with the

81
00:06:45,220 --> 00:06:47,440
name of the file itself.

82
00:06:47,440 --> 00:06:53,590
So it ends in dot J.S. meaning it is a file that contains javascript code and that's true all of the

83
00:06:53,590 --> 00:06:57,250
code we write in here is gonna be plain old JavaScript.

84
00:06:57,250 --> 00:07:04,480
The dot test extension that makes sure that gest knows this file contains and test cases that we want

85
00:07:04,480 --> 00:07:11,710
to run so down below it saying that it checked 10 files but wasn't able to find any test cases because

86
00:07:11,740 --> 00:07:17,290
none of the files in our project had that dot test dot J asked extension.

87
00:07:17,290 --> 00:07:24,130
Now that we do have a file that has this extension let's go ahead and run NPM test one more time.

88
00:07:24,130 --> 00:07:25,690
Now it's still not gonna work.

89
00:07:25,720 --> 00:07:29,620
But it's going to fail for a different reason right here.

90
00:07:29,620 --> 00:07:36,360
We'll use clear to clear the terminal and NPM test to rerun just one more time.

91
00:07:36,370 --> 00:07:39,570
Right here we can see that it has indeed failed.

92
00:07:39,580 --> 00:07:41,710
And if we scroll up we will see why.

93
00:07:42,070 --> 00:07:49,570
So right here it did detect our file math dot test dot J S in the test directory.

94
00:07:49,630 --> 00:07:56,830
Right here we're getting the following message test suite failed to run and it says that our test suite

95
00:07:56,920 --> 00:08:00,290
must contain at least one test.

96
00:08:00,700 --> 00:08:07,120
So right now just as saying that our test cases have failed because we have a file but it doesn't have

97
00:08:07,120 --> 00:08:08,300
any tests.

98
00:08:08,350 --> 00:08:14,710
So let's go ahead and fix that by actually creating our very first test case to create your first test

99
00:08:14,710 --> 00:08:15,160
case.

100
00:08:15,160 --> 00:08:18,530
All you have to do is call the test function.

101
00:08:18,550 --> 00:08:25,180
Now you'll notice that the test function is not being loaded in with anything like a require just actually

102
00:08:25,180 --> 00:08:31,190
provides the test function as a global in your test suite files.

103
00:08:31,240 --> 00:08:34,040
Now just provides other Global's as well.

104
00:08:34,120 --> 00:08:37,990
And we'll explore those as we continue through the section for now.

105
00:08:37,990 --> 00:08:44,290
All you need to know is that in your test suite you call test to set up a new test.

106
00:08:44,320 --> 00:08:47,500
Now right here when we call it we provide it two arguments.

107
00:08:47,500 --> 00:08:51,610
The first is a string and the second is a function.

108
00:08:51,610 --> 00:08:55,080
The string is the name for your test case.

109
00:08:55,120 --> 00:09:02,530
So I could say something like user should not be able to sign up with a password shorter than X characters

110
00:09:02,860 --> 00:09:07,810
for the moment though we'll go ahead and say something like hello world.

111
00:09:07,810 --> 00:09:08,890
Perfect.

112
00:09:08,890 --> 00:09:11,860
So now we have our test case name in place.

113
00:09:11,860 --> 00:09:13,700
And here we have the function.

114
00:09:13,930 --> 00:09:20,560
The function contains the code you want to run to actually verify that the given feature is working

115
00:09:20,560 --> 00:09:21,860
as expected.

116
00:09:21,880 --> 00:09:28,330
Now for the moment we're going to leave that function completely empty and simply save the file with

117
00:09:28,330 --> 00:09:29,680
this change in place.

118
00:09:29,830 --> 00:09:31,570
Down below from the terminal.

119
00:09:31,630 --> 00:09:38,680
Once again I'll be clearing the terminal output and using NPM test to rerun that test suite.

120
00:09:38,680 --> 00:09:43,280
And right here we can see it is looking through math dot test dot J.

121
00:09:43,280 --> 00:09:46,930
S and right here our test suite is now passing.

122
00:09:47,290 --> 00:09:49,950
I have a little checkmark next to my test case.

123
00:09:49,960 --> 00:09:53,800
Hello world with some statistics down below.

124
00:09:53,830 --> 00:10:00,680
So right here we have a passing test suite even though this function does absolutely no thing now this

125
00:10:00,680 --> 00:10:05,480
test case isn't doing anything but it is considered a passing test case.

126
00:10:05,480 --> 00:10:06,990
So why is that.

127
00:10:07,070 --> 00:10:13,850
When we register a test we call the test function providing a name and the function when Jesse runs

128
00:10:13,850 --> 00:10:14,550
our tests.

129
00:10:14,570 --> 00:10:16,780
It simply runs that function.

130
00:10:16,910 --> 00:10:22,030
If the function throws an error then the test case is considered a failure.

131
00:10:22,040 --> 00:10:27,920
If the function does not throw an error then the test case is considered a success.

132
00:10:27,950 --> 00:10:28,830
So down below.

133
00:10:28,850 --> 00:10:35,870
Let's go ahead and call test a second time to set up a second test case for the name I'll pick something

134
00:10:35,870 --> 00:10:38,420
like this should fail.

135
00:10:38,420 --> 00:10:41,020
Then I'll go ahead and provide that second argument.

136
00:10:41,030 --> 00:10:49,910
The function to run and to actually make this test case fail over going to do is throw a new error with

137
00:10:49,910 --> 00:10:53,070
the following message failure.

138
00:10:53,300 --> 00:10:54,830
Perfect right here.

139
00:10:54,830 --> 00:11:02,390
We're going to save the test suite down below I'll use clear to clear the terminal output and NPM test

140
00:11:02,420 --> 00:11:04,790
to run that test suite again.

141
00:11:04,790 --> 00:11:12,410
Right here I would expect just to find my file run both tests and down below we can see that is exactly

142
00:11:12,410 --> 00:11:13,610
what's happening.

143
00:11:13,670 --> 00:11:17,140
So right here we have our general summary test suites.

144
00:11:17,180 --> 00:11:20,850
We have 1 total test suite and it has indeed failed.

145
00:11:20,900 --> 00:11:28,220
And down below individual test cases I have two total tests one passed and one failed.

146
00:11:28,220 --> 00:11:32,750
Now if I scroll up I can get some more information about the one that did fail.

147
00:11:32,750 --> 00:11:37,270
Right here I can see which ones succeeded and which ones failed.

148
00:11:37,310 --> 00:11:43,520
I have the error message that was provided and I can also see exactly where that occurred in the test

149
00:11:43,640 --> 00:11:44,570
case.

150
00:11:44,570 --> 00:11:49,550
So there we go when we're creating tests over doing is creating functions.

151
00:11:49,610 --> 00:11:53,240
If everything worked as expected we don't throw an error.

152
00:11:53,300 --> 00:11:56,410
If something went wrong we do throw an error.

153
00:11:56,480 --> 00:12:01,240
Now we could use this approach to test a simple function that adds up to numbers.

154
00:12:01,280 --> 00:12:09,110
We can also use this approach to try to log in to our Express API with invalid credentials making sure

155
00:12:09,110 --> 00:12:11,660
that we don't get an off token back.

156
00:12:11,660 --> 00:12:18,260
So this simple principle is going to be able to be expanded into more complex real world scenarios.

157
00:12:18,350 --> 00:12:24,620
So down below let's take a quick moment to talk about why we want to write test cases for our projects

158
00:12:24,650 --> 00:12:25,260
right here.

159
00:12:25,280 --> 00:12:29,350
I have a few key points though there are others so why test.

160
00:12:29,360 --> 00:12:32,070
First up testing saves time.

161
00:12:32,090 --> 00:12:35,490
Now yes you have to write more code but that's OK.

162
00:12:35,570 --> 00:12:41,960
We write code wants to test a specific feature and we can run it as many times as we'd like.

163
00:12:41,990 --> 00:12:45,840
So if I create a new feature I create a test case for it.

164
00:12:45,890 --> 00:12:52,430
Then over the next four or five years of development I can keep just running that test case automatically

165
00:12:52,610 --> 00:12:54,350
by running the test command.

166
00:12:54,350 --> 00:12:59,030
There's no need to recreate it or do any manual work whatsoever.

167
00:12:59,030 --> 00:13:03,230
Now this is gonna be even greater as your application grows in size.

168
00:13:03,260 --> 00:13:09,920
It will no longer be feasible to manually test everything and you'll rely on an automatic test suite.

169
00:13:10,010 --> 00:13:12,200
Which brings us to the second point.

170
00:13:12,200 --> 00:13:16,490
When we test our code we create more reliable software.

171
00:13:16,490 --> 00:13:22,370
So whether you're just creating a project for yourself or working with a company or trying to launch

172
00:13:22,400 --> 00:13:28,300
a startup writing test cases is going to make it much easier to create reliable code.

173
00:13:28,520 --> 00:13:35,720
You'll be able to spot and fix bugs before they actually get shipped to production and mess up users.

174
00:13:35,720 --> 00:13:41,450
So we will have a test suite that makes sure everything is working and if something in our application

175
00:13:41,450 --> 00:13:46,700
was to break one of our test cases would fail alerting us that something's wrong.

176
00:13:47,030 --> 00:13:53,090
If we run the test suite and all of our test cases are passing then we know everything is working as

177
00:13:53,090 --> 00:13:58,660
expected and we could have a little more peace of mind that our software is functional.

178
00:13:58,730 --> 00:14:04,330
Now when we have a test suite in place it also gives flexibility to developers.

179
00:14:04,400 --> 00:14:09,500
I can refactor code trying to do things in a different or faster way.

180
00:14:09,500 --> 00:14:15,650
And as long as my test cases are passing I know I haven't broken anything I've just changed how something

181
00:14:15,650 --> 00:14:16,640
is done.

182
00:14:16,670 --> 00:14:20,310
It also makes it much easier when collaborating with others.

183
00:14:20,330 --> 00:14:25,880
If someone's coming into your project to add a feature or fix something they might not be up to speed

184
00:14:25,880 --> 00:14:30,140
on all of the different features of the software and how they fit together.

185
00:14:30,200 --> 00:14:36,770
When you have an automatic test suite that new developer can simply run the test cases and ensure that

186
00:14:36,770 --> 00:14:41,310
they haven't broken anything when they changed one area of the project.

187
00:14:41,480 --> 00:14:48,080
You can also do a bit of profiling so you can see if these speed your test cases run goes up or down

188
00:14:48,110 --> 00:14:54,260
as you make changes so you can slowly make your application faster and faster over time.

189
00:14:54,260 --> 00:14:58,210
And lastly a point I already mentioned is peace of mind.

190
00:14:58,310 --> 00:15:00,800
You'll know that you have an automatic test suite.

191
00:15:00,810 --> 00:15:05,510
You can run to verify your entire project in a matter of seconds.

192
00:15:05,550 --> 00:15:10,990
If I wanted to make sure the task manager was completely functional I would have to go over to post

193
00:15:10,990 --> 00:15:11,740
man.

194
00:15:11,760 --> 00:15:17,490
I'd have to fire off a bunch of different requests changing things to make sure I got the correct errors

195
00:15:17,490 --> 00:15:19,830
when bad data was provided.

196
00:15:19,830 --> 00:15:24,450
It wouldn't be a slow process and there would be a lot of room for human error.

197
00:15:24,450 --> 00:15:30,240
It's possible that I would see the results and not realize they're incorrect when we have a code based

198
00:15:30,300 --> 00:15:31,500
test case.

199
00:15:31,500 --> 00:15:37,950
We can rerun our entire test suite by typing out six characters and waiting a few seconds.

200
00:15:37,950 --> 00:15:42,900
That's powerful and it's going to allow us to create better software over time.

201
00:15:43,080 --> 00:15:49,830
So I am really excited to dive into testing because it is such an important feature in the next lesson.

202
00:15:49,920 --> 00:15:54,100
We're going to create some test cases for a few example functions.

203
00:15:54,120 --> 00:15:55,280
I'm excited to get to that.

204
00:15:55,290 --> 00:15:56,730
So let's jump right in.