1
00:00:00,040 --> 00:00:03,520
Welcome to the Deep Dive, where 
we unpack complex ideas to give 

2
00:00:03,520 --> 00:00:05,840
you those really insightful 
takeaways. 

3
00:00:06,360 --> 00:00:09,400
Today we're digging into 
something pretty powerful, but 

4
00:00:09,400 --> 00:00:11,960
maybe a bit misunderstood 
sometimes in software 

5
00:00:11,960 --> 00:00:15,240
development mocks. 
Yeah, that's right. 

6
00:00:15,240 --> 00:00:18,880
And our our guide for this is 
Marco Tulio Valente's Software 

7
00:00:18,880 --> 00:00:22,520
Engineering a Modern Approach. 
It's a really solid resource, 

8
00:00:22,600 --> 00:00:25,000
gives you practical insights, 
especially, you know, when you 

9
00:00:25,000 --> 00:00:26,600
get into unit testing. 
Absolutely. 

10
00:00:26,880 --> 00:00:28,440
So our mission today is pretty 
clear. 

11
00:00:29,200 --> 00:00:32,520
Let's really get our heads 
around what mocks are, why 

12
00:00:32,520 --> 00:00:36,480
they're actually quite essential
for good software development, 

13
00:00:36,720 --> 00:00:39,520
and how they solve this really 
common problem you run into when

14
00:00:39,520 --> 00:00:41,520
you're trying to write tests 
that are, well, efficient and 

15
00:00:41,520 --> 00:00:44,160
focused. 
We want you to walk away feeling

16
00:00:44,160 --> 00:00:46,840
like you really grasp it without
getting overloaded. 

17
00:00:47,160 --> 00:00:48,840
So let's just jump in. 
OK, so when you're building 

18
00:00:48,840 --> 00:00:51,400
software, you hit this challenge
pretty early on, right? 

19
00:00:51,400 --> 00:00:54,040
You want to test the small 
parts, the individual pieces of 

20
00:00:54,040 --> 00:00:56,320
your code. 
That's that's basically what a 

21
00:00:56,320 --> 00:00:59,640
unit test is for, checking one 
isolated component, making sure 

22
00:00:59,640 --> 00:01:03,000
it works like it should. 
But what happens when that small

23
00:01:03,000 --> 00:01:06,200
unit, that little component, 
actually depends on something 

24
00:01:06,680 --> 00:01:08,520
you know, bigger something 
outside itself? 

25
00:01:08,520 --> 00:01:10,280
Yeah, that's that's a classic 
scenario. 

26
00:01:10,520 --> 00:01:13,280
The source Valente's book uses a
great example. 

27
00:01:13,880 --> 00:01:15,720
Think about a class called book 
search. 

28
00:01:16,040 --> 00:01:17,880
Simple enough. 
OK, it's job. 

29
00:01:17,880 --> 00:01:21,240
It's got a method maybe get book
and it needs to find books. 

30
00:01:21,400 --> 00:01:24,680
But here's the kicker. 
To do that search, it doesn't 

31
00:01:24,680 --> 00:01:27,120
just look inside the 
application, it relies on 

32
00:01:27,120 --> 00:01:28,800
something called a book 
repository a. 

33
00:01:28,800 --> 00:01:31,160
Repository. 
So like a database? 

34
00:01:31,560 --> 00:01:34,760
Sort of, but in this example, 
think of the book repository as 

35
00:01:34,760 --> 00:01:36,600
representing an external 
service. 

36
00:01:36,600 --> 00:01:40,360
Maybe it's a REST API somewhere 
else on another server entirely?

37
00:01:40,720 --> 00:01:42,360
OK, like calling out over the 
network? 

38
00:01:42,360 --> 00:01:44,560
Exactly. 
So when get book runs, it 

39
00:01:44,560 --> 00:01:47,000
actually reaches out to this 
remote repository, grabs the 

40
00:01:47,000 --> 00:01:50,760
results maybe in Jason format, 
which is pretty standard, and 

41
00:01:50,760 --> 00:01:53,920
then it uses that data to create
a Book object inside your 

42
00:01:53,920 --> 00:01:55,040
application. 
Right. 

43
00:01:55,040 --> 00:01:56,760
And I can already see where this
might get tricky. 

44
00:01:57,000 --> 00:02:01,040
If you want a unit test that get
book method, letting it talk to 

45
00:02:01,040 --> 00:02:04,680
a real remote server every time 
you run the test, why is that 

46
00:02:04,680 --> 00:02:06,920
actually a problem? 
Why not just let it connect? 

47
00:02:07,040 --> 00:02:10,199
Well, there are two really core 
problems with that approach, 

48
00:02:10,199 --> 00:02:13,560
especially for unit tests. 
The book lays them out clearly. 

49
00:02:13,760 --> 00:02:16,200
First one is what we call scope 
expansion. 

50
00:02:16,280 --> 00:02:19,200
Scope expansion meaning. 
Meaning a unit test is supposed 

51
00:02:19,200 --> 00:02:21,440
to focus on just one small 
thing, right? 

52
00:02:21,440 --> 00:02:25,320
It's whole point is isolation. 
Verify this component, the book 

53
00:02:25,320 --> 00:02:28,680
search class in our example. 
But the second you let it talk 

54
00:02:28,680 --> 00:02:33,240
to an external service, boom, 
your test scope just exploded. 

55
00:02:33,760 --> 00:02:35,640
So you're not just testing book 
search anymore? 

56
00:02:35,640 --> 00:02:37,360
Exactly. 
You're suddenly testing the 

57
00:02:37,360 --> 00:02:39,560
network. 
Is the remote server up? 

58
00:02:39,880 --> 00:02:42,880
Is it working correctly? 
The test loses that crucial 

59
00:02:42,880 --> 00:02:44,920
isolation. 
It's not really a unit test in 

60
00:02:44,920 --> 00:02:46,880
the true sense anymore. 
OK, that makes sense. 

61
00:02:46,880 --> 00:02:48,960
It muddies the waters. 
What's the second big issue? 

62
00:02:49,080 --> 00:02:51,520
The second one is a big 
performance hit. 

63
00:02:51,520 --> 00:02:54,520
I mean, think about it, 
accessing a remote service that 

64
00:02:54,520 --> 00:02:56,880
involves network calls may be 
delayed. 

65
00:02:57,040 --> 00:02:59,400
Things can be slow. 
Yeah, definitely slower than 

66
00:02:59,400 --> 00:03:02,000
just running code locally. 
Way slower. 

67
00:03:02,440 --> 00:03:05,240
And that goes against a 
fundamental idea of good unit 

68
00:03:05,240 --> 00:03:07,120
tests. 
They need to be fast. 

69
00:03:07,160 --> 00:03:08,760
Super fast. 
Ideally. 

70
00:03:09,480 --> 00:03:11,480
Remember the first principles 
for testing. 

71
00:03:11,560 --> 00:03:15,120
The F is for fast. 
If your tests take ages to run, 

72
00:03:15,320 --> 00:03:17,400
developers just won't run them 
as often. 

73
00:03:17,520 --> 00:03:19,320
Right, you lose that quick 
feedback loop. 

74
00:03:19,600 --> 00:03:21,240
If it takes minutes, you'll 
hesitate. 

75
00:03:21,240 --> 00:03:23,240
If it takes seconds, you run 
them all the time. 

76
00:03:23,240 --> 00:03:25,680
Precisely. 
Slow tests really hurt 

77
00:03:25,680 --> 00:03:29,480
productivity and confidence. 
You want to catch bugs quickly, 

78
00:03:29,480 --> 00:03:31,640
not hours later. 
OK, so we've got this clear 

79
00:03:31,640 --> 00:03:33,240
challenge. 
We need to test our little book 

80
00:03:33,240 --> 00:03:36,400
search class, but it depends on 
this external book repository 

81
00:03:36,400 --> 00:03:40,880
which is slow and kind of 
outside our direct control for 

82
00:03:40,880 --> 00:03:43,120
the test. 
How do we keep our unit tests 

83
00:03:43,160 --> 00:03:47,120
fast and isolated, true to that 
unit idea without just, you 

84
00:03:47,120 --> 00:03:49,680
know, ignoring the dependency? 
And that brings us neatly to the

85
00:03:49,680 --> 00:03:52,400
solution mocks. 
It's quite an elegant idea 

86
00:03:52,400 --> 00:03:53,880
actually. 
OK, tell me about mocks. 

87
00:03:54,200 --> 00:03:57,320
A mock at its heart is basically
an object you create 

88
00:03:57,320 --> 00:04:00,240
specifically to pretend to be 
the real object, but only during

89
00:04:00,240 --> 00:04:03,120
your tests. 
It emulates the real things 

90
00:04:03,120 --> 00:04:04,960
behavior, but in a controlled 
way. 

91
00:04:05,680 --> 00:04:07,360
It's worth mentioning the author
here. 

92
00:04:07,360 --> 00:04:11,440
Valente uses mock and stub 
pretty interchangeably. 

93
00:04:11,480 --> 00:04:13,000
We're focusing on that practical
idea. 

94
00:04:13,000 --> 00:04:14,920
A stand in for test. 
A stand in. 

95
00:04:14,960 --> 00:04:18,959
OK, so how does that apply back 
to our book search example? 

96
00:04:18,959 --> 00:04:21,920
Yeah, how do we use a mock to 
get around that slow book 

97
00:04:21,920 --> 00:04:24,080
repository? 
It's pretty clever in practice. 

98
00:04:24,080 --> 00:04:27,200
Instead of letting book search 
talk to the real remote book 

99
00:04:27,200 --> 00:04:29,120
repository, you create a fake 
one. 

100
00:04:29,120 --> 00:04:31,000
Let's call it Mock Book 
repository. 

101
00:04:31,400 --> 00:04:34,960
Now the crucial part is this. 
This mock book repository looks 

102
00:04:34,960 --> 00:04:37,480
exactly the same to book search 
as the real one. 

103
00:04:37,840 --> 00:04:40,440
It implements the same 
interface, the same methods. 

104
00:04:40,760 --> 00:04:43,040
So book search doesn't even know
it's talking to a fake. 

105
00:04:43,040 --> 00:04:45,520
It has no idea, it just calls 
the methods it expects. 

106
00:04:45,520 --> 00:04:48,640
But the inside of the mock book 
repository is totally different.

107
00:04:48,640 --> 00:04:50,240
How so? 
It's super simple. 

108
00:04:50,440 --> 00:04:52,880
It doesn't make any network 
calls, it doesn't talk to any 

109
00:04:52,880 --> 00:04:54,720
remote server, it doesn't wait 
for anything. 

110
00:04:55,040 --> 00:04:58,480
Instead, when you call it search
methods, say with a specific 

111
00:04:58,480 --> 00:05:02,720
ISBN like 1234, it just 
instantly returns some 

112
00:05:02,720 --> 00:05:05,960
predefined data, like maybe a 
fixed Jason string that 

113
00:05:05,960 --> 00:05:07,720
represents the software 
engineering book. 

114
00:05:07,880 --> 00:05:09,440
OK, so it's hard coded 
basically. 

115
00:05:09,520 --> 00:05:10,960
Pretty much for the test's 
purpose. 

116
00:05:10,960 --> 00:05:14,560
For any other ISBN, maybe it 
just returns a null book string.

117
00:05:14,560 --> 00:05:16,880
You control exactly what it 
returns instantly. 

118
00:05:17,160 --> 00:05:20,320
The source mentions maybe 
storing these predefined strings

119
00:05:20,320 --> 00:05:23,760
in like a a book construction 
class just to keep them tidy. 

120
00:05:23,800 --> 00:05:25,760
Got it. 
Consistent, predictable data. 

121
00:05:25,760 --> 00:05:28,040
Exactly. 
So then your test set up your 

122
00:05:28,040 --> 00:05:29,760
book search test. 
It creates the book search 

123
00:05:29,760 --> 00:05:32,560
object, but instead instead of 
giving it the real repository, 

124
00:05:32,760 --> 00:05:34,960
it gives it this mock book 
repository and. 

125
00:05:34,960 --> 00:05:37,120
That lets the test run without 
hitting the network. 

126
00:05:37,200 --> 00:05:39,520
Bingo. 
The test get book method runs. 

127
00:05:39,560 --> 00:05:42,760
It calls the mock, gets instant 
predictable Jason back and does 

128
00:05:42,760 --> 00:05:45,440
its thing. 
The whole test runs super fast, 

129
00:05:45,440 --> 00:05:47,640
completely isolated, no network 
involved. 

130
00:05:47,920 --> 00:05:51,120
That is brilliant. 
OK, so we've made the test fast.

131
00:05:51,120 --> 00:05:54,600
We've isolated it from the 
external world, focusing purely 

132
00:05:54,600 --> 00:05:56,200
on book search. 
But that brings up a really 

133
00:05:56,200 --> 00:05:59,320
important question. 
If we're using this mock, this 

134
00:05:59,320 --> 00:06:03,080
standard that just gives back 
canned data, what are we 

135
00:06:03,080 --> 00:06:05,320
actually testing? 
What requirement are we checking

136
00:06:05,320 --> 00:06:07,040
here? 
It's obviously not testing the 

137
00:06:07,040 --> 00:06:10,160
real connection anymore. 
That's a really key point to 

138
00:06:10,160 --> 00:06:13,440
understand and you're spot on. 
The test when using a mock like 

139
00:06:13,440 --> 00:06:16,280
this is not testing the access 
to the remote service. 

140
00:06:16,280 --> 00:06:19,240
That's just not its job, OK. 
Testing whether you can actually

141
00:06:19,240 --> 00:06:22,480
connect to the real remote 
server and get real data, that's

142
00:06:22,480 --> 00:06:25,200
a different kind of testing. 
Maybe an integration test or a 

143
00:06:25,200 --> 00:06:28,080
system test. 
It's important, but it's outside

144
00:06:28,080 --> 00:06:31,560
the scope of this unit test. 
So what is this unit test 

145
00:06:31,560 --> 00:06:34,160
verifying then? 
What it is verifying, the core 

146
00:06:34,160 --> 00:06:35,920
requirement it's checking is. 
This. 

147
00:06:36,280 --> 00:06:40,280
Is the logic for creating a Book
object from a Jason document 

148
00:06:40,280 --> 00:06:43,240
working correctly? 
So it's about the transformation

149
00:06:43,240 --> 00:06:46,400
within my code. 
Precisely, you're using the mock

150
00:06:46,480 --> 00:06:50,080
to guarantee you get predictable
input that specific Jason 

151
00:06:50,080 --> 00:06:52,360
string. 
Then you're checking if your 

152
00:06:52,360 --> 00:06:55,720
book search code correctly 
parses that Jason takes the 

153
00:06:55,720 --> 00:06:59,480
right data out and successfully 
creates the book object with the

154
00:06:59,480 --> 00:07:00,960
right properties. 
I see. 

155
00:07:00,960 --> 00:07:04,240
So it's all about testing the 
internal logic, the processing 

156
00:07:04,240 --> 00:07:06,120
inside the book search class 
itself. 

157
00:07:06,360 --> 00:07:09,440
Given a known input, We're 
taking the external dependency 

158
00:07:09,440 --> 00:07:11,800
out of the equation for this 
specific test. 

159
00:07:11,880 --> 00:07:14,480
Exactly. 
You're ensuring your own codes, 

160
00:07:14,480 --> 00:07:17,800
transformation, parsing and 
object creation logic is sound, 

161
00:07:18,160 --> 00:07:21,400
regardless of what the outside 
world the real service might be 

162
00:07:21,400 --> 00:07:23,640
doing at that moment. 
It gives developers huge 

163
00:07:23,640 --> 00:07:25,560
confidence. 
That makes so much sense. 

164
00:07:25,560 --> 00:07:28,600
It's like saying I know the 
input will look like this thanks

165
00:07:28,600 --> 00:07:30,960
to the mock. 
Now let me make absolutely sure 

166
00:07:30,960 --> 00:07:32,920
my code handles this input 
correctly. 

167
00:07:33,160 --> 00:07:37,080
It isolates the responsibility. 
Right, and you can refactor your

168
00:07:37,080 --> 00:07:39,640
internal book search logic, 
change how it parses things, and

169
00:07:39,640 --> 00:07:42,200
be confident your unit test will
tell you if you broke that 

170
00:07:42,200 --> 00:07:45,200
internal logic without worrying 
about network glitches or the 

171
00:07:45,200 --> 00:07:48,000
remote service being down. 
And I guess you can easily 

172
00:07:48,000 --> 00:07:51,320
extend that mock, right? 
Add more predefined books, test 

173
00:07:51,320 --> 00:07:54,600
edge cases with different Jason 
formats that might return, test 

174
00:07:54,600 --> 00:07:58,480
more fields, all without 
touching the real external 

175
00:07:58,480 --> 00:07:59,600
system. 
Absolutely. 

176
00:07:59,600 --> 00:08:02,600
You can make the mock return 
different canned responses to 

177
00:08:02,600 --> 00:08:05,960
test various scenarios within 
your book search logic, making 

178
00:08:05,960 --> 00:08:08,880
your tests incredibly robust for
the code you actually control. 

179
00:08:08,880 --> 00:08:11,480
OK, that's a real aha moment. 
For me. 

180
00:08:11,880 --> 00:08:15,760
It's about focusing the unit 
test laser sharp on the unit 

181
00:08:15,760 --> 00:08:17,920
itself. 
That's the power of mocks in 

182
00:08:17,920 --> 00:08:19,960
unit testing. 
Well, hopefully this deep dive 

183
00:08:19,960 --> 00:08:23,920
into mocks has really clarified 
how these these clever emulators

184
00:08:23,920 --> 00:08:27,280
help developers write tests that
are faster, much more reliable, 

185
00:08:27,480 --> 00:08:29,640
and really focused on the actual
unit of code. 

186
00:08:30,040 --> 00:08:32,400
It's definitely a key technique 
for, you know, staying 

187
00:08:32,400 --> 00:08:34,360
productive and confident when 
you're building complex 

188
00:08:34,360 --> 00:08:36,360
software. 
Understanding how to isolate 

189
00:08:36,360 --> 00:08:39,480
things properly really helps you
build faster and with fewer 

190
00:08:39,480 --> 00:08:41,640
nasty surprises. 
Yeah, absolutely. 

191
00:08:41,640 --> 00:08:43,440
Thank you for joining us on this
deep dive today.