1
00:00:06,540 --> 00:00:08,173
- So far, we've seen how to define

2
00:00:08,173 --> 00:00:11,820
a custom jest matcher that
receives a single parameter

3
00:00:11,820 --> 00:00:14,430
which specifies the value to test.

4
00:00:14,430 --> 00:00:16,890
It's also possible to
define a jest matcher

5
00:00:16,890 --> 00:00:18,660
that receives several parameters.

6
00:00:18,660 --> 00:00:20,910
The first parameter is always the value

7
00:00:20,910 --> 00:00:23,820
that you're trying to test,
and then additional parameters

8
00:00:23,820 --> 00:00:27,090
help you specify constraints
such as minimum value

9
00:00:27,090 --> 00:00:30,330
and the maximum value within
which the number should be.

10
00:00:30,330 --> 00:00:32,293
So what we'll do now
we'll see how to define

11
00:00:32,293 --> 00:00:35,850
a custom matcher that receives
additional parameters.

12
00:00:35,850 --> 00:00:37,710
Here's our custom matcher,

13
00:00:37,710 --> 00:00:40,950
it's in the custom jest matchers folder.

14
00:00:40,950 --> 00:00:44,250
And I defined a file called setuptests.js,

15
00:00:44,250 --> 00:00:46,590
which contains my custom matchers.

16
00:00:46,590 --> 00:00:49,410
Okay. So let's have a look
at that on the file system.

17
00:00:49,410 --> 00:00:54,120
If you go into jstdd, lesson
two, custom jest matchers.

18
00:00:54,120 --> 00:00:56,742
And if you open that
folder in the code editor,

19
00:00:56,742 --> 00:00:58,350
this is what it looks like.

20
00:00:58,350 --> 00:01:01,860
As you can see, we have a setuptest.js,

21
00:01:01,860 --> 00:01:05,550
and in here I define two
custom jest matchers.

22
00:01:05,550 --> 00:01:08,910
Remember how it works when
you define custom matcher.

23
00:01:08,910 --> 00:01:11,910
You have to call the
expect extend function

24
00:01:11,910 --> 00:01:14,070
and then you have to pass it an object.

25
00:01:14,070 --> 00:01:15,210
And then in that object,

26
00:01:15,210 --> 00:01:17,550
you can define your custom matchers.

27
00:01:17,550 --> 00:01:20,760
So I defined, well, first of
all, the example from before,

28
00:01:20,760 --> 00:01:24,250
a simple jest matcher that
just received the value to test

29
00:01:25,110 --> 00:01:27,090
to be between zero and a hundred.

30
00:01:27,090 --> 00:01:30,000
And now I've got a more
general jest matcher

31
00:01:30,000 --> 00:01:32,400
where the constraints,
the minimum and maximum

32
00:01:32,400 --> 00:01:35,700
aren't hard coded, but
they're parameterized.

33
00:01:35,700 --> 00:01:37,590
Okay. So you can specify the minimum

34
00:01:37,590 --> 00:01:41,370
and the maximum value within
which that number should lie.

35
00:01:41,370 --> 00:01:43,680
So here's the code in my PowerPoint,

36
00:01:43,680 --> 00:01:45,120
highlighting the relevant bits.

37
00:01:45,120 --> 00:01:47,850
As you can see the
number, you always receive

38
00:01:47,850 --> 00:01:50,280
at least one parameter in a custom matcher

39
00:01:50,280 --> 00:01:51,900
the value that you are testing,

40
00:01:51,900 --> 00:01:53,550
plus any other parameters

41
00:01:53,550 --> 00:01:56,220
which help you formulate
your test condition.

42
00:01:56,220 --> 00:02:00,090
So similar to the example
from earlier, first of all,

43
00:02:00,090 --> 00:02:01,560
let's make sure that the number

44
00:02:01,560 --> 00:02:03,392
or the parameter really is a number.

45
00:02:03,392 --> 00:02:07,350
And if it isn't, we fail
immediately, it's unconditional,

46
00:02:07,350 --> 00:02:10,770
you know, it has to be a
number that we're checking.

47
00:02:10,770 --> 00:02:15,480
Then if it is a number, we
establish, if it's in range.

48
00:02:15,480 --> 00:02:18,507
If it is, then we return true.

49
00:02:18,507 --> 00:02:21,270
If the test condition from the user

50
00:02:21,270 --> 00:02:23,040
was hoping that it wasn't in range,

51
00:02:23,040 --> 00:02:24,840
then this would then fail, okay.

52
00:02:24,840 --> 00:02:27,240
Because they were hoping
the number wasn't in range,

53
00:02:27,240 --> 00:02:30,183
but in fact, it is in the
range of minimum or maximum.

54
00:02:31,410 --> 00:02:35,520
Alternatively, if the number
is too small or too large,

55
00:02:35,520 --> 00:02:38,070
we come down here, we return false,

56
00:02:38,070 --> 00:02:40,770
the test condition wasn't satisfied.

57
00:02:40,770 --> 00:02:42,840
And if the user was
hoping it was satisfied,

58
00:02:42,840 --> 00:02:44,280
they'll get this error message.

59
00:02:44,280 --> 00:02:47,640
We expected the number to be
in this range, and it wasn't.

60
00:02:47,640 --> 00:02:51,000
Oh, do you like my
mathematical notation here?

61
00:02:51,000 --> 00:02:55,080
In the print message, I use
square brackets to indicate

62
00:02:55,080 --> 00:02:59,190
an inclusive min, lower
bound and easy for me to say.

63
00:02:59,190 --> 00:03:00,900
And I use a long bracket here

64
00:03:00,900 --> 00:03:03,540
to express an exclusive upper bound.

65
00:03:03,540 --> 00:03:06,810
That's a mathematical way of
saying inclusive lower bound,

66
00:03:06,810 --> 00:03:08,403
exclusive upper bound.

67
00:03:09,300 --> 00:03:12,933
So anyway that's my custom
matcher defined in setuptests.js.

68
00:03:14,280 --> 00:03:17,850
And if you remember, there
isn't any automatic naming

69
00:03:17,850 --> 00:03:19,260
convention for these files.

70
00:03:19,260 --> 00:03:22,740
We happen to define our
custom matchers in this file

71
00:03:22,740 --> 00:03:25,230
but jest doesn't look there instinctively.

72
00:03:25,230 --> 00:03:27,420
You have to tell it where to look

73
00:03:27,420 --> 00:03:28,770
to find your custom matchers.

74
00:03:28,770 --> 00:03:33,770
So as before, we have to
define the jest config JS file

75
00:03:33,810 --> 00:03:36,690
and in there, we have to
basically tell it what file

76
00:03:36,690 --> 00:03:39,290
or files contain our custom matchers.

77
00:03:39,290 --> 00:03:44,290
Okay? So in my project, I've
also defined that file as well.

78
00:03:44,430 --> 00:03:45,630
And you can see it here.

79
00:03:47,340 --> 00:03:51,870
So jest will know where to look
to find my custom matchers.

80
00:03:51,870 --> 00:03:54,270
So the last thing to do is to actually use

81
00:03:54,270 --> 00:03:56,310
our custom matchers in a test.

82
00:03:56,310 --> 00:04:00,360
So here's my test suite
using to be in range

83
00:04:00,360 --> 00:04:02,850
to be in range, being my custom matcher.

84
00:04:02,850 --> 00:04:06,420
So in this file, in this test suite,

85
00:04:06,420 --> 00:04:08,934
I've defined various functions that check

86
00:04:08,934 --> 00:04:12,240
or that use that custom matcher.

87
00:04:12,240 --> 00:04:15,090
So let's take a look at those tests.

88
00:04:15,090 --> 00:04:19,290
So an example test JS,
and in the last suite,

89
00:04:19,290 --> 00:04:22,350
the first three suites
I check in the exam mark

90
00:04:22,350 --> 00:04:23,183
custom matcher.

91
00:04:23,183 --> 00:04:25,200
We've seen that already,

92
00:04:25,200 --> 00:04:27,120
now we'll focus on the new one.

93
00:04:27,120 --> 00:04:29,403
The parameterized custom matcher.

94
00:04:30,420 --> 00:04:33,090
Okay. So as you can see,
when you call the function,

95
00:04:33,090 --> 00:04:35,640
the function itself
receives three parameters.

96
00:04:35,640 --> 00:04:37,860
The first parameter is always the value

97
00:04:37,860 --> 00:04:39,270
that you're trying to check.

98
00:04:39,270 --> 00:04:40,530
And then the other two parameters

99
00:04:40,530 --> 00:04:42,330
are the additional parameters.

100
00:04:42,330 --> 00:04:44,640
So jest will actually call that function,

101
00:04:44,640 --> 00:04:47,280
it'll pass 10 as the first parameter

102
00:04:47,280 --> 00:04:52,140
and that as the minimum, and
that as the maximum, okay.

103
00:04:52,140 --> 00:04:57,140
So if my custom matcher
is correct, then it should

104
00:04:57,210 --> 00:05:00,990
successfully indicate that
10 is within that range.

105
00:05:00,990 --> 00:05:03,060
Inclusive, lower bound,

106
00:05:03,060 --> 00:05:05,580
up 19 is also within that range,

107
00:05:05,580 --> 00:05:08,115
hopefully my custom matcher will say yes,

108
00:05:08,115 --> 00:05:11,970
nine should not be in the
range because it's too small.

109
00:05:11,970 --> 00:05:14,550
And 20 shouldn't be in the range either

110
00:05:14,550 --> 00:05:15,570
because it's too large.

111
00:05:15,570 --> 00:05:18,123
Because if my custom matcher is correct,

112
00:05:19,290 --> 00:05:21,660
it's exclusive on the upper bound.

113
00:05:21,660 --> 00:05:24,090
So my custom matcher should indicate

114
00:05:24,090 --> 00:05:27,093
that 20 isn't in the range.

115
00:05:28,110 --> 00:05:31,980
Okay. So all of these tests should pass.

116
00:05:31,980 --> 00:05:36,330
Likewise, these tests, each
of these tests should fail.

117
00:05:36,330 --> 00:05:38,910
Okay. So if the user passed in a number,

118
00:05:38,910 --> 00:05:40,860
hoping it was within range,

119
00:05:40,860 --> 00:05:42,690
my custom matcher should realize,

120
00:05:42,690 --> 00:05:45,203
well it isn't, and it
should raise an error

121
00:05:45,203 --> 00:05:48,000
or it should gimme back an error message.

122
00:05:48,000 --> 00:05:49,590
I should say, it should fail the test.

123
00:05:49,590 --> 00:05:53,640
My custom matcher should
fail because the number

124
00:05:53,640 --> 00:05:56,340
the user was hoping to be in range isn't

125
00:05:56,340 --> 00:05:59,550
and my custom matcher should
tell me that it isn't in range.

126
00:05:59,550 --> 00:06:01,260
So it's the same thing for these.

127
00:06:01,260 --> 00:06:03,870
If the user was hoping that
this test was in range,

128
00:06:03,870 --> 00:06:06,510
my custom matcher should fail.

129
00:06:06,510 --> 00:06:08,820
In other words, it should
return false, I mean.

130
00:06:08,820 --> 00:06:11,400
Likewise, if the user was hoping a number

131
00:06:11,400 --> 00:06:14,160
wasn't in range, well,
that number is in range

132
00:06:14,160 --> 00:06:16,290
and my custom matcher should say,

133
00:06:16,290 --> 00:06:18,810
no, no that number actually is in range

134
00:06:18,810 --> 00:06:20,280
and you were hoping it wasn't.

135
00:06:20,280 --> 00:06:22,230
If you get the pulliam logic.

136
00:06:22,230 --> 00:06:27,180
When you have a test
with multiple assertions,

137
00:06:27,180 --> 00:06:29,430
if one of those assertion fails,

138
00:06:29,430 --> 00:06:32,760
it doesn't get any further in the test.

139
00:06:32,760 --> 00:06:35,820
So if this first statement failed,

140
00:06:35,820 --> 00:06:38,910
it wouldn't bother
executing the other tests.

141
00:06:38,910 --> 00:06:43,140
So what I could do is
I could run this test

142
00:06:43,140 --> 00:06:45,720
four times, kind of uncomment

143
00:06:45,720 --> 00:06:47,520
in each one of these one at a time.

144
00:06:47,520 --> 00:06:49,200
And for the sake of the demo,

145
00:06:49,200 --> 00:06:52,200
I just comment out the other three.

146
00:06:52,200 --> 00:06:55,650
Okay. So when it runs this test,

147
00:06:55,650 --> 00:07:00,650
that expectation should
fail with an error message.

148
00:07:02,280 --> 00:07:05,220
So we'll run these tests.

149
00:07:05,220 --> 00:07:09,780
To run the tests, usual
arrangement, you run yarn or npm

150
00:07:09,780 --> 00:07:12,930
and you specify a partial string

151
00:07:12,930 --> 00:07:16,350
which selects the suite that
we're trying to execute.

152
00:07:16,350 --> 00:07:20,580
Okay. So let's do that
now and see what happens.

153
00:07:20,580 --> 00:07:25,580
So npm run test parameters at minus t

154
00:07:25,590 --> 00:07:30,590
and good to be specify
in using to be in range.

155
00:07:33,263 --> 00:07:37,633
Okay. So pluck out my,
using to be in range suite,

156
00:07:38,610 --> 00:07:40,830
it'll run my two test functions.

157
00:07:40,830 --> 00:07:43,140
The first test function will pass

158
00:07:43,140 --> 00:07:45,750
and the second test function should fail

159
00:07:45,750 --> 00:07:49,320
because the user
inadvertently, there we go.

160
00:07:49,320 --> 00:07:51,390
So using to be in range,

161
00:07:51,390 --> 00:07:55,083
the first test passed and
the second test failed.

162
00:07:56,310 --> 00:07:57,143
There we go.

163
00:07:58,320 --> 00:08:00,660
Okay, so that's the failure there.

164
00:08:00,660 --> 00:08:02,880
And the error message that we get,

165
00:08:02,880 --> 00:08:05,490
expected nine to be in range 10 20.

166
00:08:05,490 --> 00:08:07,680
Well, that's what the user hoped for,

167
00:08:07,680 --> 00:08:09,120
they passed in that number,

168
00:08:09,120 --> 00:08:10,950
hoping it would be in that range.

169
00:08:10,950 --> 00:08:14,910
My matcher successfully
realized that it wasn't actually

170
00:08:14,910 --> 00:08:16,620
and it gave me an error message.

171
00:08:16,620 --> 00:08:19,410
I'm gonna try that one more time.

172
00:08:19,410 --> 00:08:23,730
This time with one of the kind
of opposite condition tests

173
00:08:23,730 --> 00:08:24,990
if you understand.

174
00:08:24,990 --> 00:08:28,080
So if I come back in here,
I'll comment that one out

175
00:08:28,080 --> 00:08:29,940
and I'll comment, uncomment this one.

176
00:08:29,940 --> 00:08:31,710
I want to see what the error message is

177
00:08:31,710 --> 00:08:33,570
if the user is expecting something

178
00:08:33,570 --> 00:08:36,000
not to be in range when in fact it is.

179
00:08:36,000 --> 00:08:38,940
I want to see that the error
message is appropriate.

180
00:08:38,940 --> 00:08:41,760
In that case, you were
expecting it not to be in range

181
00:08:41,760 --> 00:08:42,990
and it actually is in range.

182
00:08:42,990 --> 00:08:45,840
Let's see what happens
when I run that test.

183
00:08:45,840 --> 00:08:47,670
So I'll run that test again.

184
00:08:47,670 --> 00:08:50,250
As before the first test will pass

185
00:08:50,250 --> 00:08:51,971
and the second test will fail

186
00:08:51,971 --> 00:08:54,090
but I'm looking for a
different error message now.

187
00:08:54,090 --> 00:08:55,390
So let's see what happens.

188
00:08:56,798 --> 00:08:58,830
Okay. So the first test function passed,

189
00:08:58,830 --> 00:08:59,663
that's good.

190
00:08:59,663 --> 00:09:00,930
And the second test function failed,

191
00:09:00,930 --> 00:09:03,330
which is also good in our condition.

192
00:09:03,330 --> 00:09:05,100
We were hoping it would fail, weren't we?

193
00:09:05,100 --> 00:09:08,820
And the error message, according
to what the user specified,

194
00:09:08,820 --> 00:09:12,780
they were hoping that that
number would be in range.

195
00:09:12,780 --> 00:09:14,864
Okay. But the number they passed in...

196
00:09:14,864 --> 00:09:15,697
Oh, sorry,

197
00:09:15,697 --> 00:09:17,730
they were hoping that the
number wouldn't be in range.

198
00:09:17,730 --> 00:09:19,710
In fact, it is.

199
00:09:19,710 --> 00:09:22,620
So what's the error
message that we get back.

200
00:09:22,620 --> 00:09:25,353
You were expecting 10
not to be in the range.

201
00:09:26,550 --> 00:09:27,390
Weren't you?

202
00:09:27,390 --> 00:09:30,300
You were expecting 10 not to be in range.

203
00:09:30,300 --> 00:09:33,960
In fact it was, therefore the test fails.

204
00:09:33,960 --> 00:09:38,370
So right then custom matchers
is relatively straightforward.

205
00:09:38,370 --> 00:09:42,150
The only tricky thing is
to understand the, you know

206
00:09:42,150 --> 00:09:44,430
are you testing whether
there's a true condition

207
00:09:44,430 --> 00:09:45,810
or false condition

208
00:09:45,810 --> 00:09:48,300
and then return in a
suitable error message

209
00:09:48,300 --> 00:09:50,613
if it's the opposite to what you expect.