1
00:00:00,080 --> 00:00:03,440
OK, let's unpack this. 
Have you ever felt, you know, 

2
00:00:03,440 --> 00:00:07,080
just swamped by information, 
trying to really get a handle on

3
00:00:07,080 --> 00:00:09,720
something new quickly but also 
properly? 

4
00:00:10,240 --> 00:00:13,040
Well, that's exactly why we do 
what we do here on the deep 

5
00:00:13,040 --> 00:00:14,800
dive. 
Our whole mission is to sort of 

6
00:00:14,800 --> 00:00:17,720
cut through the noise, pull out 
the really important stuff from 

7
00:00:17,720 --> 00:00:21,320
different sources and hopefully 
give you that aha moment. 

8
00:00:22,440 --> 00:00:24,280
Today we're diving into 
something pretty crucial. 

9
00:00:24,280 --> 00:00:26,080
If you're into software 
development or really just 

10
00:00:26,080 --> 00:00:28,040
building things that actually 
work reliably. 

11
00:00:28,320 --> 00:00:31,400
Unit testing. 
This deep dive is based on some 

12
00:00:31,720 --> 00:00:34,840
really interesting bits from 
Software engineering, a modern 

13
00:00:34,840 --> 00:00:38,520
approach by Marco Tulio Valente.
We're going to explore why unit 

14
00:00:38,520 --> 00:00:42,000
tests are like everywhere now, 
and how they help make sure 

15
00:00:42,000 --> 00:00:44,120
software is up to scratch. 
Yeah. 

16
00:00:44,120 --> 00:00:46,600
And if we kind of step back for 
a second before we get into the,

17
00:00:46,960 --> 00:00:50,120
you know, the nuts and bolts of 
unit testing itself, it helps to

18
00:00:50,120 --> 00:00:53,440
remember what we're fighting 
against, so to speak, defects, 

19
00:00:53,440 --> 00:00:55,880
bugs, basically times when the 
code doesn't do what it's 

20
00:00:55,880 --> 00:00:59,160
supposed to do, and failures. 
That's when that buggy code 

21
00:00:59,160 --> 00:01:00,880
actually runs and causes a 
problem. 

22
00:01:01,280 --> 00:01:03,880
Unit tests are what one of our 
best tools for catching those 

23
00:01:03,880 --> 00:01:07,120
issues early on, right? 
So that brings us straight to 

24
00:01:07,120 --> 00:01:10,480
section 8.2 in the book, 
focusing specifically on unit 

25
00:01:10,480 --> 00:01:12,160
testing. 
Let's dig in. 

26
00:01:12,280 --> 00:01:15,880
What exactly are unit tests? 
What's really fascinating here, 

27
00:01:15,880 --> 00:01:18,480
I think, is how clearly the 
source defines them. 

28
00:01:18,720 --> 00:01:22,520
Unit tests are automated tests, 
OK, and they focus on these 

29
00:01:22,520 --> 00:01:25,480
small units of code, usually 
classes. 

30
00:01:25,800 --> 00:01:29,080
But the key insight, the really 
important bit, is that these 

31
00:01:29,080 --> 00:01:32,440
units are tested in isolation, 
completely separate from the 

32
00:01:32,440 --> 00:01:33,760
rest of the system. 
Isolation. 

33
00:01:34,360 --> 00:01:36,760
Yeah. 
So a unit test at its heart, 

34
00:01:36,880 --> 00:01:40,040
it's just a little program that 
calls methods from a class and 

35
00:01:40,040 --> 00:01:42,480
then checks, you know, did it 
get the result that expected? 

36
00:01:42,480 --> 00:01:44,840
And the structure of a system 
that uses unit tests. 

37
00:01:45,400 --> 00:01:47,240
It sounds quite neat. 
The book shows it right. 

38
00:01:47,240 --> 00:01:48,600
You've got your main code. 
Exactly. 

39
00:01:48,600 --> 00:01:51,240
Your main classes doing the 
actual work, filling the 

40
00:01:51,240 --> 00:01:55,280
requirements and then totally 
separate you have this other set

41
00:01:55,400 --> 00:01:57,240
of test programs. 
Glue separation. 

42
00:01:57,240 --> 00:01:59,240
I like that. 
And this separation it brings up

43
00:01:59,240 --> 00:02:01,800
something interesting. 
The source shows this figure 

44
00:02:01,800 --> 00:02:05,560
right with N classes and M 
tests, and it's not one to one. 

45
00:02:05,560 --> 00:02:08,479
Oh right, so not every class 
gets exactly 1 test. 

46
00:02:08,759 --> 00:02:11,000
Not at all. 
You might have one really 

47
00:02:11,000 --> 00:02:13,520
critical class, maybe it handles
payments or something. 

48
00:02:13,760 --> 00:02:17,200
And it might have, I don't know,
1020 unit tests hitting it from 

49
00:02:17,200 --> 00:02:18,520
different angles, different 
scenarios. 

50
00:02:18,920 --> 00:02:21,800
And then conversely, you might 
have some simple classes, maybe 

51
00:02:21,800 --> 00:02:26,440
just data holders with very few 
tests, or maybe none if they're 

52
00:02:26,440 --> 00:02:28,800
super trivial or tested 
indirectly. 

53
00:02:28,800 --> 00:02:31,160
So it's flexible. 
It depends on what the code 

54
00:02:31,160 --> 00:02:32,200
does. 
Precisely. 

55
00:02:32,600 --> 00:02:35,840
That visual really shows it's 
about focusing effort where it 

56
00:02:35,840 --> 00:02:38,160
matters most. 
Complexity importance. 

57
00:02:38,240 --> 00:02:41,280
OK, that makes sense. 
So we know what they are testing

58
00:02:41,280 --> 00:02:44,920
small bits in isolation. 
But how do developers actually, 

59
00:02:45,080 --> 00:02:46,840
you know, do this? 
They don't just write them a 

60
00:02:46,840 --> 00:02:49,080
notepad, right? 
No, definitely not. 

61
00:02:49,400 --> 00:02:52,880
You use specialized frameworks, 
tools built just for this job. 

62
00:02:53,440 --> 00:02:55,800
And the most famous family of 
these frameworks is called X 

63
00:02:55,800 --> 00:02:58,080
Unit. 
The X is just a placeholder, 

64
00:02:58,080 --> 00:02:59,480
really. 
It stands for whatever language 

65
00:02:59,480 --> 00:03:00,560
you're using. 
X Unit. 

66
00:03:00,560 --> 00:03:02,000
Yeah. 
It's got a history, goes back to

67
00:03:02,000 --> 00:03:05,200
the late 80s, actually. 
A guy named Kent Beck made the 

68
00:03:05,200 --> 00:03:07,840
first one unit for a language 
called Small Talk. 

69
00:03:08,040 --> 00:03:09,800
Wow. 
OK, so it's been around a while.

70
00:03:09,960 --> 00:03:13,560
It has, and maybe the one people
know best today, especially in 

71
00:03:13,560 --> 00:03:16,960
the Java world, is J Unit. 
J Unit, Yeah, I've heard of that

72
00:03:16,960 --> 00:03:18,640
one. 
So the first version of J Unit 

73
00:03:18,640 --> 00:03:20,880
Kent Beck again, along with Eric
Gamma. 

74
00:03:21,800 --> 00:03:25,600
They apparently hammered it out 
on a plane trip back in 97. 

75
00:03:25,600 --> 00:03:29,400
No way on a plane. 
That's the story kind of cool, 

76
00:03:29,400 --> 00:03:30,880
right? 
Shows you can do when you're 

77
00:03:30,880 --> 00:03:32,560
focused I guess. 
Definitely. 

78
00:03:32,880 --> 00:03:37,040
So these frameworks J unit X 
unit, they're available for lots

79
00:03:37,040 --> 00:03:38,640
of languages. 
Oh yeah, that's the huge 

80
00:03:38,640 --> 00:03:40,280
advantage. 
Pretty much any mainstream 

81
00:03:40,280 --> 00:03:43,680
language you can think of. 
Java, Python, C#, JavaScript, 

82
00:03:43,680 --> 00:03:46,120
Ruby, you name it. 
It's got an X unit style 

83
00:03:46,120 --> 00:03:49,040
framework, which means 
developers don't have to learn 

84
00:03:49,040 --> 00:03:51,920
some whole new testing language.
They write the tests in the same

85
00:03:51,920 --> 00:03:53,360
language they're building the 
system in. 

86
00:03:53,640 --> 00:03:55,680
Uses all the same skills, same 
tools. 

87
00:03:55,880 --> 00:03:58,840
Makes it much easier to adopt. 
Right, seamless integration. 

88
00:03:58,840 --> 00:04:01,360
That's smart. 
So to make this a bit more real,

89
00:04:01,360 --> 00:04:03,200
the source uses an example, 
doesn't it? 

90
00:04:03,280 --> 00:04:05,400
A stack class. 
It does a classic data 

91
00:04:05,400 --> 00:04:07,720
structure, the stack you 
probably remember, it's like a, 

92
00:04:07,960 --> 00:04:11,360
well, a stack of plates. 
Last in, first out Ifo. 

93
00:04:11,640 --> 00:04:13,240
Exactly. 
You can push things onto the 

94
00:04:13,240 --> 00:04:16,120
top, pop them off the top, check
the size, see if it is empty. 

95
00:04:16,240 --> 00:04:19,079
Simple stuff, and it also has 
this specific rule. 

96
00:04:19,640 --> 00:04:22,680
If you try to pop from an empty 
stack, it's supposed to throw an

97
00:04:22,680 --> 00:04:26,000
error an empty stack exception. 
Simple example but good for 

98
00:04:26,000 --> 00:04:29,320
showing the testing process. 
And when you use J unit, there 

99
00:04:29,320 --> 00:04:31,360
are conventions little rules to 
follow. 

100
00:04:31,360 --> 00:04:35,240
Like the test class is usually 
named after the class it tests, 

101
00:04:35,640 --> 00:04:38,880
but with test on the end. 
So stack class gets a stack test

102
00:04:38,880 --> 00:04:40,840
class. 
Makes sense, Easy to find. 

103
00:04:41,200 --> 00:04:44,520
And the methods inside stack 
test that actually do the 

104
00:04:44,520 --> 00:04:47,560
testing, they also have rules. 
They usually start with test 

105
00:04:47,560 --> 00:04:51,120
like test is empty or test push.
They need to be public, no 

106
00:04:51,120 --> 00:04:53,280
parameters. 
And critically, they have this 

107
00:04:53,280 --> 00:04:56,040
at Test thing right before them.
An annotation. 

108
00:04:56,120 --> 00:04:58,240
An annotation like A tag? 
Yeah, exactly like A tag. 

109
00:04:58,240 --> 00:05:00,720
It's how you tell June it. 
Hey, this method right here. 

110
00:05:00,800 --> 00:05:02,400
Run it as a test. 
Got it. 

111
00:05:02,760 --> 00:05:06,240
So what is one of these test 
something methods actually do 

112
00:05:06,240 --> 00:05:08,800
inside? 
Well, a typical unit test method

113
00:05:08,800 --> 00:05:12,680
follows this nice clean pattern.
Three steps basically. 

114
00:05:13,400 --> 00:05:15,880
First, you set things up. 
Create the object you're 

115
00:05:15,880 --> 00:05:17,440
testing. 
This is something that's called 

116
00:05:17,440 --> 00:05:18,960
setting up the fixture for the 
stack. 

117
00:05:19,240 --> 00:05:21,880
You just create a new stack 
instance stack, my stack? 

118
00:05:22,120 --> 00:05:23,040
Who's that? 
Something like that. 

119
00:05:23,040 --> 00:05:25,080
OK, step. 
One create the thing to test. 

120
00:05:25,240 --> 00:05:27,720
Step 2. 
You call the method you're 

121
00:05:27,720 --> 00:05:30,520
interested in like you'd call my
stack dot is empty. 

122
00:05:30,760 --> 00:05:32,120
Perform the. 
Action step three. 

123
00:05:32,440 --> 00:05:36,000
Check the result. 
Exactly step three, verify the 

124
00:05:36,000 --> 00:05:38,440
result. 
You use special assert commands 

125
00:05:38,440 --> 00:05:40,440
provided by JUnit. 
There are lots of them, like 

126
00:05:40,440 --> 00:05:42,760
assert true, assert equals 
assert NOT NULL. 

127
00:05:43,480 --> 00:05:47,080
So for is empty. 
On a brand new stack, you'd use 

128
00:05:47,080 --> 00:05:49,840
assert TRUE. 
My stack dot is empty, so you're

129
00:05:49,840 --> 00:05:51,760
asserting. 
I expect this to be true. 

130
00:05:51,760 --> 00:05:54,960
OK, setup ACT assert, that's 
pretty clear. 

131
00:05:54,960 --> 00:05:57,400
And running these tests you 
mentioned the IDE. 

132
00:05:57,560 --> 00:05:58,720
Helps. 
Yeah, your development 

133
00:05:58,720 --> 00:06:01,080
environment, your IDE makes this
super easy. 

134
00:06:01,080 --> 00:06:03,120
You don't run the whole 
application, there's usually 

135
00:06:03,120 --> 00:06:05,840
just a right click option run as
test or something similar. 

136
00:06:06,000 --> 00:06:09,480
It finds all those at Test 
methods and just runs them super

137
00:06:09,480 --> 00:06:10,320
quick. 
And when they pav. 

138
00:06:10,560 --> 00:06:13,040
You get a nice clean output 
green bar. 

139
00:06:13,040 --> 00:06:17,200
Usually it'll say something like
15 tests run, zero failure, 0 

140
00:06:17,200 --> 00:06:20,200
errors, and it tells you how 
fast it was, often just 

141
00:06:20,200 --> 00:06:22,040
milliseconds. 
Milliseconds. 

142
00:06:22,200 --> 00:06:24,040
Wow. 
Yeah, that speed is huge. 

143
00:06:24,200 --> 00:06:26,720
It means you can run these tests
constantly while you're coding, 

144
00:06:26,720 --> 00:06:29,480
get feedback almost instantly if
you break something, OK. 

145
00:06:29,480 --> 00:06:30,760
But what about when things go 
wrong? 

146
00:06:30,760 --> 00:06:33,080
The source gives an example of a
bug, right? 

147
00:06:33,080 --> 00:06:36,240
Like if the stack size started 
at 1 instead of 0. 

148
00:06:36,240 --> 00:06:38,800
Wait, a subtle bug? 
Maybe someone type size equal 1 

149
00:06:38,800 --> 00:06:42,600
instead of ize equals 0 when 
initializing the stack O. 

150
00:06:42,600 --> 00:06:45,800
Now, if you create a new stack 
and immediately call Waze emty, 

151
00:06:45,960 --> 00:06:48,600
it's going to return false 
because it thinks there's one 

152
00:06:48,600 --> 00:06:49,880
item in there, even though there
isn't. 

153
00:06:49,880 --> 00:06:53,200
And the test that assert true my
stack is empty. 

154
00:06:53,280 --> 00:06:56,000
That test would fail. 
Unit calls this a failure 

155
00:06:56,280 --> 00:06:59,120
specifically meaning an 
assertion didn't hold true. 

156
00:06:59,160 --> 00:07:00,640
The result wasn't what you 
expected. 

157
00:07:00,640 --> 00:07:02,440
So you get a red bar instead of 
green. 

158
00:07:02,520 --> 00:07:05,240
You bet. 
Red bar big failure text. 

159
00:07:05,400 --> 00:07:09,000
Yeah, and crucially, you get an 
error message like assertion 

160
00:07:09,000 --> 00:07:11,200
failed error. 
It'll tell you exactly which 

161
00:07:11,200 --> 00:07:14,520
assertion failed, what it 
expected true, and what it 

162
00:07:14,520 --> 00:07:17,440
actually got false. 
So it points you right to the 

163
00:07:17,440 --> 00:07:18,520
problem. 
Directly. 

164
00:07:18,880 --> 00:07:23,240
That immediate, specific 
feedback is incredibly powerful 

165
00:07:23,360 --> 00:07:26,200
for fixing bugs quickly. 
The source then shows a more 

166
00:07:26,200 --> 00:07:29,480
fleshed out stack test class 
right with more tests. 

167
00:07:29,600 --> 00:07:32,680
Yeah, it shows examples like 
test note empty stack checking 

168
00:07:32,680 --> 00:07:35,560
it's not empty after pushing, 
test size stack checking the 

169
00:07:35,560 --> 00:07:39,280
size after pushes, test push pop
stack, making sure pushing then 

170
00:07:39,280 --> 00:07:42,520
popping get you back the same 
item, just covering more bases. 

171
00:07:42,840 --> 00:07:46,480
And there was something about 
setting up at before each. 

172
00:07:46,760 --> 00:07:49,200
Ah yes, that's a really useful 
1. 

173
00:07:49,280 --> 00:07:52,320
You can write a method often 
called in it or setup and put 

174
00:07:52,320 --> 00:07:53,960
the app before each annotation 
on it. 

175
00:07:54,240 --> 00:07:57,080
What Joe Unit does then is it 
runs that setup method 

176
00:07:57,080 --> 00:08:00,160
automatically before it runs 
every single at Test method in 

177
00:08:00,160 --> 00:08:02,120
the class. 
Oh OK, so instead of creating a 

178
00:08:02,120 --> 00:08:04,680
new stack inside each test 
method. 

179
00:08:04,680 --> 00:08:06,560
You can do it once in the app 
before each method. 

180
00:08:06,600 --> 00:08:09,600
It guarantees every test starts 
with a fresh identical stack, 

181
00:08:09,600 --> 00:08:12,440
and since yeah, no interference 
between tests really important 

182
00:08:12,440 --> 00:08:15,080
for reliable results. 
It avoids repeating that setup 

183
00:08:15,080 --> 00:08:16,560
code everywhere too. 
That's clever. 

184
00:08:16,560 --> 00:08:18,040
Keeps things clean. 
Definitely. 

185
00:08:18,360 --> 00:08:22,080
So the whole JUnit process is 
basically find a test class, 

186
00:08:22,360 --> 00:08:25,520
then for every at Test method 
inside it make a new instance of

187
00:08:25,520 --> 00:08:28,320
the test class. 
Run any app before each method. 

188
00:08:28,560 --> 00:08:32,559
Run the at Test method itself. 
Repeat isolation and consistency

189
00:08:33,159 --> 00:08:34,679
all. 
The way and one last thing, 

190
00:08:34,760 --> 00:08:38,240
testing for expected errors like
that empty stack exception. 

191
00:08:38,280 --> 00:08:39,679
Right, you need to test that 
too. 

192
00:08:39,679 --> 00:08:42,159
If the code is supposed to throw
an exception under certain 

193
00:08:42,159 --> 00:08:46,360
conditions, you need to verify 
that it does June at 5, which 

194
00:08:46,360 --> 00:08:49,560
the source refers to. 
Version 5 to 10 specifically has

195
00:08:49,560 --> 00:08:51,440
a nice way to do this using a 
cert throws. 

196
00:08:51,520 --> 00:08:54,240
How does that work? 
You basically tell it I expect 

197
00:08:54,240 --> 00:08:58,360
this specific exception like 
empty stack exception dot class 

198
00:08:58,600 --> 00:09:00,520
to be thrown when this piece of 
code runs. 

199
00:09:01,080 --> 00:09:03,560
You often provide that piece of 
code as a little inline function

200
00:09:03,560 --> 00:09:06,240
of Lambda. 
If the runs and throws exactly 

201
00:09:06,240 --> 00:09:09,800
that exception, the test passes.
If it throws nothing or throws a

202
00:09:09,800 --> 00:09:11,880
different exception, the test 
fails. 

203
00:09:12,000 --> 00:09:13,880
Got it. 
So you can even test the error 

204
00:09:13,880 --> 00:09:15,640
handling. 
That's pretty comprehensive. 

205
00:09:15,640 --> 00:09:17,880
It really aims to be. 
You want confidence that your 

206
00:09:17,880 --> 00:09:20,680
code works correctly in normal 
situations and handles errors 

207
00:09:20,680 --> 00:09:22,880
properly. 
So wrapping up then, we've taken

208
00:09:22,880 --> 00:09:24,760
this deep dive into unit 
testing. 

209
00:09:25,120 --> 00:09:29,160
We've seen it's about testing 
small isolated pieces of code. 

210
00:09:29,400 --> 00:09:32,160
Using frameworks like JNET 
following conventions like 

211
00:09:32,160 --> 00:09:34,760
naming and annotations. 
Running tests quickly and 

212
00:09:34,760 --> 00:09:37,880
getting immediate feedback, 
especially when things fail. 

213
00:09:38,280 --> 00:09:41,360
And using features like at 
before each for clean setup and 

214
00:09:41,360 --> 00:09:42,960
assert throws for error 
checking. 

215
00:09:43,040 --> 00:09:46,200
It really paints a picture of 
how crucial this is for building

216
00:09:46,200 --> 00:09:49,160
solid software. 
Absolutely that focus on 

217
00:09:49,160 --> 00:09:52,400
automated testing right down at 
the smallest level the unit. 

218
00:09:52,880 --> 00:09:55,800
It's just fundamental these days
for building anything complex 

219
00:09:55,800 --> 00:09:58,080
and reliable. 
It builds confidence and quality

220
00:09:58,080 --> 00:10:00,160
from the ground U. 
Well, thank you for joining us 

221
00:10:00,160 --> 00:10:00,960
on this Dee dive.