1
00:00:00,040 --> 00:00:03,240
Welcome to the Deep Dive, where 
we take a stack of information 

2
00:00:03,240 --> 00:00:06,240
and extract the most important 
Nuggets for you, our curious 

3
00:00:06,240 --> 00:00:08,000
listener. 
Today we're embarking on a 

4
00:00:08,000 --> 00:00:12,520
fascinating journey, really 
getting into a crucial corner of

5
00:00:12,520 --> 00:00:16,760
software engineering, the world 
of mocks and mock frameworks in 

6
00:00:16,760 --> 00:00:18,680
testing. 
Now it might sound a bit 

7
00:00:18,680 --> 00:00:20,960
technical at first, but 
honestly, it's absolutely 

8
00:00:20,960 --> 00:00:23,520
foundational if you want to 
build software that's, you know,

9
00:00:23,600 --> 00:00:27,200
robust and reliable. 
Our guide for this deep dive is 

10
00:00:27,200 --> 00:00:30,520
Software engineering a modern 
approach by Marco Tulio Valente.

11
00:00:30,960 --> 00:00:33,960
We'll be focusing specifically 
on how developers well, how they

12
00:00:33,960 --> 00:00:37,080
streamline and simplify a really
critical part of the software 

13
00:00:37,080 --> 00:00:40,000
testing process, making it much 
more efficient, much more 

14
00:00:40,000 --> 00:00:42,240
effective. 
Now, if you've been with us for 

15
00:00:42,240 --> 00:00:44,440
previous deep dives into 
software development, you might 

16
00:00:44,440 --> 00:00:47,520
recall us touching on the idea 
of creating simple mock objects 

17
00:00:47,520 --> 00:00:49,320
by hand. 
Think of it like this. 

18
00:00:49,320 --> 00:00:52,400
If you're testing, say, a book 
search object, you don't 

19
00:00:52,400 --> 00:00:55,760
necessarily want it hitting a 
real, potentially slow database 

20
00:00:55,760 --> 00:00:57,800
every single time you run a 
test, right? 

21
00:00:57,800 --> 00:01:00,720
So you might create a simple 
stand in a mock book repository 

22
00:01:00,960 --> 00:01:04,239
that maybe only returns data for
one specific book, just to make 

23
00:01:04,239 --> 00:01:06,920
sure that book search part is 
working correctly. 

24
00:01:06,920 --> 00:01:10,120
Totally in isolation, it, it 
lets you check your logic 

25
00:01:10,120 --> 00:01:12,080
without waiting on those 
external systems. 

26
00:01:12,560 --> 00:01:14,480
But I mean, imagine doing that 
manually. 

27
00:01:14,480 --> 00:01:17,800
What if you need dozens, maybe 
hundreds of these mocks? 

28
00:01:17,800 --> 00:01:20,600
And what if their behavior needs
to be complex, needs to change 

29
00:01:20,600 --> 00:01:23,800
depending on the specific test, 
That manual approach, well, it 

30
00:01:23,800 --> 00:01:26,320
quickly becomes a huge burden. 
It really slows things down. 

31
00:01:26,360 --> 00:01:28,120
Yeah. 
And what's fascinating here is 

32
00:01:28,120 --> 00:01:31,640
that this exact challenge, I 
mean, the sheer prevalence of 

33
00:01:31,640 --> 00:01:34,040
needing these stand in objects, 
you can call them mocks, some 

34
00:01:34,040 --> 00:01:37,960
call them stubs. 
In unit testing, it directly led

35
00:01:37,960 --> 00:01:40,320
to the development of these 
really powerful tools to 

36
00:01:40,400 --> 00:01:42,320
automate their creation and 
management. 

37
00:01:42,760 --> 00:01:45,640
These mock frameworks, they 
don't just streamline the 

38
00:01:45,640 --> 00:01:47,720
process honestly, they kind of 
transform it. 

39
00:01:47,880 --> 00:01:49,720
And that's exactly what we're 
going to unpack today. 

40
00:01:49,880 --> 00:01:52,200
How do these frameworks work 
their magic? 

41
00:01:52,200 --> 00:01:54,840
Why are they so incredibly 
beneficial for developers? 

42
00:01:55,160 --> 00:01:57,560
And maybe what do they tell us 
about the different 

43
00:01:58,120 --> 00:02:00,760
philosophical approaches to 
testing software? 

44
00:02:01,080 --> 00:02:03,480
So let's really set the stage 
for the problem these frameworks

45
00:02:03,480 --> 00:02:05,440
are designed to solve. 
We touched on creating mocks 

46
00:02:05,440 --> 00:02:08,720
manually, and yeah, for a very 
simple isolated test it might 

47
00:02:08,720 --> 00:02:11,840
seem OK, manageable. 
But in the real world of 

48
00:02:11,840 --> 00:02:14,640
software development, 
applications just aren't simple,

49
00:02:14,640 --> 00:02:15,840
are they? 
They have loads of 

50
00:02:15,840 --> 00:02:18,800
interconnected components, each 
relying on others interacting 

51
00:02:18,800 --> 00:02:21,680
with databases, external 
services, you know, payment 

52
00:02:21,680 --> 00:02:23,440
gateways, all that stuff. 
Well, absolutely. 

53
00:02:23,440 --> 00:02:26,840
I mean picture a developer 
trying to test a function that 

54
00:02:26,840 --> 00:02:30,200
processes an online order. 
That single function might 

55
00:02:30,200 --> 00:02:33,960
depend on a payment gateway, an 
inventory service, maybe an 

56
00:02:33,960 --> 00:02:36,640
e-mail notifier. 
Now if you had to manually write

57
00:02:36,640 --> 00:02:39,560
classes like mock payment 
gateway, mock inventory service,

58
00:02:39,560 --> 00:02:43,080
mock e-mail notifier and do that
for every unique test case. 

59
00:02:43,080 --> 00:02:45,800
Like one for a successful 
payment, another for a failed 

60
00:02:45,800 --> 00:02:48,400
payment, one for low inventory, 
one for out of stock. 

61
00:02:48,960 --> 00:02:51,800
You'd honestly spend more time 
writing mock code than actual 

62
00:02:51,800 --> 00:02:53,840
application code. 
It becomes unsustainable. 

63
00:02:53,840 --> 00:02:56,320
It just sounds like a mountain 
of boilerplate code, so what's 

64
00:02:56,320 --> 00:02:58,880
the real core issue with doing 
it manually like that? 

65
00:02:59,080 --> 00:03:02,080
Well, the primary issue, as our 
source highlights, is just the 

66
00:03:02,080 --> 00:03:05,480
sheer volume of repetitive code.
It's huge. 

67
00:03:06,040 --> 00:03:09,480
Each manual mock implementation,
like that mock book repository 

68
00:03:09,480 --> 00:03:12,440
example, need you to write a 
whole separate class for each 

69
00:03:12,440 --> 00:03:14,560
specific test scenario or 
behavior. 

70
00:03:15,200 --> 00:03:18,680
And this code it adds overhead, 
becomes really difficult to 

71
00:03:18,680 --> 00:03:20,840
maintain as your main 
application changes. 

72
00:03:21,280 --> 00:03:23,960
It could even introduce bugs 
into your test themselves, which

73
00:03:23,960 --> 00:03:26,720
kind of defeats the purpose. 
Remember, the whole point of a 

74
00:03:26,720 --> 00:03:30,400
mock is to allow a unit test to 
focus purely on the logic of the

75
00:03:30,400 --> 00:03:33,360
code being tested, right? 
Free from the unpredictability 

76
00:03:33,360 --> 00:03:36,680
of remote or slow services, 
Manual mocks ironically could 

77
00:03:36,680 --> 00:03:39,080
end up becoming a source of 
unpredictability and slowness in

78
00:03:39,080 --> 00:03:41,880
your testing workflow. 
OK, so what's the game changer 

79
00:03:41,880 --> 00:03:43,680
here then? 
What's the fundamental shift 

80
00:03:43,680 --> 00:03:46,440
these frameworks introduce that 
makes them such a massive step 

81
00:03:46,440 --> 00:03:49,400
forward? 
The key observation really is 

82
00:03:49,400 --> 00:03:54,160
that mock frameworks completely 
eliminate the need to implement 

83
00:03:54,160 --> 00:03:56,120
these mocks manually. 
You just don't write those 

84
00:03:56,120 --> 00:03:57,840
classes anymore. 
Instead of you writing a 

85
00:03:57,840 --> 00:04:01,080
dedicated class for each mock, 
the framework does that heavy 

86
00:04:01,080 --> 00:04:03,280
lifting for you. 
It's a real paradigm shift. 

87
00:04:03,680 --> 00:04:07,440
You go from coding the stand in 
to simply declaring the stand in

88
00:04:07,720 --> 00:04:11,400
and telling it how to behave. 
OK, Declaration, not 

89
00:04:11,400 --> 00:04:12,640
implementation. 
Exactly. 

90
00:04:12,880 --> 00:04:15,400
And this dramatically reduces 
the amount of test code you have

91
00:04:15,400 --> 00:04:18,480
to write and just as 
importantly, maintain, which in 

92
00:04:18,480 --> 00:04:21,560
turn speeds up your development 
feedback loop massively. 

93
00:04:21,839 --> 00:04:25,080
Imagine a test suite that takes 
minutes, maybe even hours to run

94
00:04:25,080 --> 00:04:27,840
because it's constantly hitting 
a real database or some slow 

95
00:04:27,840 --> 00:04:29,640
external API. 
It happens. 

96
00:04:29,920 --> 00:04:32,800
With effectively used mocks, 
that same test suite could 

97
00:04:32,800 --> 00:04:35,320
shrink down to seconds. 
It completely transforms your 

98
00:04:35,320 --> 00:04:38,680
development rhythm from like a 
painful chore into a rapid 

99
00:04:38,680 --> 00:04:41,440
continuous cycle. 
That sounds incredibly powerful.

100
00:04:41,640 --> 00:04:44,000
Our source points to a very 
popular framework that 

101
00:04:44,000 --> 00:04:47,240
exemplifies this Makito. 
Can you give us a sense of how 

102
00:04:47,240 --> 00:04:50,800
Makito actually achieves this 
simplification for a developer? 

103
00:04:51,120 --> 00:04:53,000
How does it work under the hood?
Sort of. 

104
00:04:53,120 --> 00:04:55,640
OK, let's unpack how Makito 
works its magic. 

105
00:04:55,640 --> 00:04:59,480
So instead of writing that whole
mock book repository class with 

106
00:04:59,480 --> 00:05:03,160
all its methods and logic, our 
source shows you can create a 

107
00:05:03,160 --> 00:05:06,800
mock for book repository with 
just like a single line of code.

108
00:05:07,200 --> 00:05:11,160
It's simply a call to the mock 
that Makito provides, where you 

109
00:05:11,160 --> 00:05:13,480
basically just tell it what kind
of object you want to mock, 

110
00:05:13,560 --> 00:05:16,560
interface or the class. 
Yeah, and what's truly 

111
00:05:16,560 --> 00:05:18,800
fascinating here from a 
technical standpoint is the 

112
00:05:18,800 --> 00:05:21,360
underlying technology that 
allows Makito to do this. 

113
00:05:21,600 --> 00:05:24,000
It leverages Java's reflection 
features. 

114
00:05:24,280 --> 00:05:26,520
Now, for those maybe not 
familiar, reflection basically 

115
00:05:26,520 --> 00:05:29,840
means a program can, while it's 
running, look at and even 

116
00:05:29,840 --> 00:05:31,800
manipulate its own structure and
behavior. 

117
00:05:31,800 --> 00:05:33,960
Right, it can inspect itself 
exactly. 

118
00:05:34,400 --> 00:05:38,600
So Mockito uses reflection to 
dynamically create these mock 

119
00:05:38,600 --> 00:05:41,120
objects, these substitute 
versions of your real 

120
00:05:41,120 --> 00:05:44,640
dependencies without you needing
to write a concrete class for 

121
00:05:44,640 --> 00:05:47,160
them yourself. 
You simply tell Mockito, hey, I 

122
00:05:47,160 --> 00:05:49,840
need a mock of Book repository 
and boom, it conjures one up for

123
00:05:49,840 --> 00:05:50,280
you. 
OK. 

124
00:05:50,440 --> 00:05:54,040
So the mock is created, but it's
initially just an empty shell, 

125
00:05:54,040 --> 00:05:55,400
right? 
Like it doesn't know how to 

126
00:05:55,400 --> 00:05:57,560
behave automatically. 
It won't magically return a 

127
00:05:57,560 --> 00:06:01,320
specific book or throw an error.
You have to explicitly tell it 

128
00:06:01,320 --> 00:06:05,000
what to do for your test. 
Precisely Once that mock object 

129
00:06:05,000 --> 00:06:07,360
is created, it's essentially a 
blank slate. 

130
00:06:07,600 --> 00:06:10,800
It has no inherent behavior. 
You then configure its behavior 

131
00:06:10,800 --> 00:06:14,080
to respond in very specific 
ways, exactly as needed for 

132
00:06:14,080 --> 00:06:15,960
whatever your test case is 
trying to verify. 

133
00:06:16,840 --> 00:06:19,880
And for this configuration step,
Makito offers what our source 

134
00:06:19,880 --> 00:06:22,960
calls a simple Domain Specific 
Language or DSL. 

135
00:06:23,080 --> 00:06:25,240
ADSL. 
OK, yeah, think of a DSL is like

136
00:06:25,240 --> 00:06:27,520
a mini language designed for a 
very particular purpose. 

137
00:06:28,040 --> 00:06:31,080
In this case, it's a set of 
method calls and syntax within 

138
00:06:31,080 --> 00:06:33,520
Java itself. 
But it reads almost like plain 

139
00:06:33,520 --> 00:06:36,440
English when you're defining how
your mock should behave. 

140
00:06:36,680 --> 00:06:39,760
It's designed to be intuitive. 
That sounds much better than 

141
00:06:39,760 --> 00:06:42,760
writing a whole class. 
Can you give us an example how 

142
00:06:42,760 --> 00:06:46,480
does that configuration actually
look in practice using this DSL?

143
00:06:46,520 --> 00:06:49,640
Sure, you define its responses 
to specific method calls. 

144
00:06:50,160 --> 00:06:52,120
The source gives a couple of 
really clear examples. 

145
00:06:52,280 --> 00:06:54,880
For instance, the first one 
would like something like when 

146
00:06:54,880 --> 00:06:58,120
the mock repo dot search and E&A
ends that return book hunts dot 

147
00:06:58,120 --> 00:07:01,840
null book and then maybe a 
second line when mock repo dot 

148
00:07:01,840 --> 00:07:05,040
search 1234 that return book 
hunts softening. 

149
00:07:05,240 --> 00:07:09,000
OK, let me see if I get this the
first line when mock repo dot 

150
00:07:09,000 --> 00:07:12,920
search any int that sets a kind 
of general default rule. 

151
00:07:13,280 --> 00:07:16,280
If the search method on our mock
book repository gets called with

152
00:07:16,280 --> 00:07:19,320
any integer argument at all, it 
should just return some 

153
00:07:19,320 --> 00:07:22,480
predefined null book constant, 
maybe signaling not found. 

154
00:07:22,480 --> 00:07:24,520
It's like a catch all. 
That's exactly right, it's your 

155
00:07:24,520 --> 00:07:26,000
fall back behavior for that 
method. 

156
00:07:26,360 --> 00:07:28,160
And then the second line shows 
how you can get much more 

157
00:07:28,160 --> 00:07:31,600
specific when mock repo dot 
search 1234. 

158
00:07:31,880 --> 00:07:33,880
If a search is called 
specifically with the integer 

159
00:07:33,880 --> 00:07:37,800
1234 that it overrides that 
general rule and instead it 

160
00:07:37,800 --> 00:07:40,400
should return the actual 
software engineering book data. 

161
00:07:41,000 --> 00:07:43,560
Ah, OK, that's incredibly 
flexible then. 

162
00:07:43,760 --> 00:07:46,840
It lets you model both the 
general cases and very specific 

163
00:07:46,840 --> 00:07:50,840
edge cases without cluttering up
a mock object with complex if 

164
00:07:50,840 --> 00:07:54,960
else logic or big lookup tables.
This really highlights that time

165
00:07:54,960 --> 00:07:56,520
saving power you mentioned 
earlier. 

166
00:07:56,520 --> 00:07:58,160
Definitely. 
And I guess it also makes your 

167
00:07:58,160 --> 00:08:01,400
tests much more readable because
the expected behavior of the 

168
00:08:01,400 --> 00:08:05,200
mock it's declared right there 
inside the test setup itself. 

169
00:08:05,200 --> 00:08:07,120
Exactly. 
Test intent becomes much 

170
00:08:07,120 --> 00:08:09,160
clearer. 
OK, here's where things get 

171
00:08:09,280 --> 00:08:11,960
well, Maybe a bit more nuanced, 
potentially even confusing for 

172
00:08:11,960 --> 00:08:13,560
listeners trying to follow all 
the jargon. 

173
00:08:13,920 --> 00:08:16,480
Our source acknowledges that 
some prominent authors and 

174
00:08:16,480 --> 00:08:20,000
software testing Gerard Mazaros 
has mentioned they make a 

175
00:08:20,000 --> 00:08:22,480
distinction between mocks and 
stubs. 

176
00:08:22,760 --> 00:08:24,920
For someone trying going to get 
informed, this terminology 

177
00:08:24,920 --> 00:08:28,200
difference can be a bit tricky. 
What exactly is that distinction

178
00:08:28,200 --> 00:08:30,000
about? 
Yeah, this brings up a really 

179
00:08:30,000 --> 00:08:32,880
important discussion about the 
precise terminology within 

180
00:08:32,880 --> 00:08:36,200
software testing, and honestly 
it's a point of ongoing debate 

181
00:08:36,200 --> 00:08:39,520
in the community. 
Mazzaro's and others who follow 

182
00:08:39,520 --> 00:08:43,159
his definitions argue that a 
true mock isn't just a stand in 

183
00:08:43,159 --> 00:08:45,440
for state, meaning you know what
data it returns. 

184
00:08:45,800 --> 00:08:47,760
It's also about verifying 
behavior. 

185
00:08:48,120 --> 00:08:51,440
With a mock in this stricter 
sense, you're not just 

186
00:08:51,440 --> 00:08:54,800
configuring it to return a 
value, you're also explicitly 

187
00:08:54,800 --> 00:08:57,800
verifying that your code 
interacted with that mock in a 

188
00:08:57,800 --> 00:09:00,680
specific way. 
OK, so checking if methods were 

189
00:09:00,680 --> 00:09:02,400
called. 
Right, you'd verify if 

190
00:09:02,400 --> 00:09:05,040
particular methods were called 
on the mock, maybe even the 

191
00:09:05,040 --> 00:09:07,600
order they were called in, or 
the number of times it's about 

192
00:09:07,600 --> 00:09:10,520
the collaboration. 
Conversely, if the test object 

193
00:09:10,520 --> 00:09:14,040
you're using the stand in only 
really verifies the state, like 

194
00:09:14,040 --> 00:09:16,120
in our book search example where
you just check the title of book

195
00:09:16,120 --> 00:09:19,040
that was returned by the Mac 
repository, then Mazzaros would 

196
00:09:19,040 --> 00:09:22,360
typically call that a stub. 
A stub just provides pre canned 

197
00:09:22,360 --> 00:09:24,400
answers to calls made during the
test. 

198
00:09:24,800 --> 00:09:27,200
It doesn't usually care if those
calls were made or how often. 

199
00:09:27,480 --> 00:09:30,000
So the core difference is 
whether you're asserting on the 

200
00:09:30,000 --> 00:09:32,640
return value or the data that 
comes back. 

201
00:09:32,640 --> 00:09:36,160
That's more like a stub versus 
asserting on the interaction 

202
00:09:36,320 --> 00:09:39,080
self. 
Like was this method called? 

203
00:09:40,000 --> 00:09:41,720
That's more like a mock. 
Is that the gist? 

204
00:09:41,720 --> 00:09:42,880
That's a good way to put it, 
yeah. 

205
00:09:43,120 --> 00:09:45,880
State verification versus 
interaction verification. 

206
00:09:46,200 --> 00:09:49,520
But interestingly, our source 
explicitly states it won't make 

207
00:09:49,520 --> 00:09:53,040
this distinction. 
It finds it overly nuanced for 

208
00:09:53,040 --> 00:09:55,800
its purposes. 
Why would an author choose to 

209
00:09:55,800 --> 00:09:59,440
deliberately simplify that 
terminology, especially when 

210
00:09:59,440 --> 00:10:01,240
others make a point of 
separating them? 

211
00:10:01,360 --> 00:10:04,480
What really comes down to a 
pragmatic choice and it reflects

212
00:10:04,480 --> 00:10:06,440
a common perspective you see in 
the industry. 

213
00:10:07,040 --> 00:10:09,880
The author likely believes that 
for many practical day-to-day 

214
00:10:09,880 --> 00:10:13,800
purposes, the general term mock 
is understood broadly enough to 

215
00:10:13,800 --> 00:10:16,960
cover both scenarios, and the 
benefits of going into dub 

216
00:10:16,960 --> 00:10:20,400
detail distinguishing these 
similar concepts maybe don't 

217
00:10:20,400 --> 00:10:23,600
outweigh the cost of adding more
paragraphs, more complexity to 

218
00:10:23,600 --> 00:10:25,480
the explanation. 
Right, keeping the focus 

219
00:10:25,480 --> 00:10:27,200
practical. 
Exactly. 

220
00:10:27,560 --> 00:10:30,640
It avoids bogging down the 
reader in what some might 

221
00:10:30,640 --> 00:10:33,520
consider somewhat academic 
distinctions when the core 

222
00:10:33,520 --> 00:10:37,560
purpose, which is isolating code
for testing, remains the same in

223
00:10:37,560 --> 00:10:40,560
both cases. 
However, it is worth noting, 

224
00:10:40,560 --> 00:10:44,480
like you said, that for very 
complex systems or perhaps teams

225
00:10:44,480 --> 00:10:46,600
that are really deeply invested 
in particular testing 

226
00:10:46,600 --> 00:10:49,280
methodologies like Behavior 
Driven Development, 

227
00:10:49,800 --> 00:10:52,760
understanding this nuance 
between mocks and stubs can 

228
00:10:52,760 --> 00:10:56,400
actually lead to clearer test 
intent and sometimes even better

229
00:10:56,400 --> 00:10:59,400
architectural decisions down the
line, but for a general 

230
00:10:59,400 --> 00:11:01,160
introduction may be less 
critical. 

231
00:11:01,200 --> 00:11:03,120
That makes sense. 
It's that classic trade off 

232
00:11:03,120 --> 00:11:05,920
between conceptual purity and 
practical simplicity. 

233
00:11:06,480 --> 00:11:10,120
So connecting back to that IDEA 
interaction, what then is a 

234
00:11:10,120 --> 00:11:13,000
behavioral test or interaction 
test as the source mentions? 

235
00:11:13,200 --> 00:11:15,760
Right, so that terminology 
refers specifically to text that

236
00:11:15,760 --> 00:11:17,920
do focus on those interactions 
we just discussed. 

237
00:11:18,200 --> 00:11:21,040
Instead of primarily checking a 
return value or a final state, 

238
00:11:21,240 --> 00:11:24,080
you're checking for specific 
events like method calls that 

239
00:11:24,080 --> 00:11:26,760
occurred on your mock object 
during the execution of your 

240
00:11:26,760 --> 00:11:28,160
test. 
OK, so you're verifying the 

241
00:11:28,160 --> 00:11:30,440
conversation between objects. 
Precisely. 

242
00:11:31,040 --> 00:11:33,920
The source gives a great example
using Mockito's verify command. 

243
00:11:34,680 --> 00:11:38,000
Imagine a test scenario where 
you want to confirm that after a

244
00:11:38,000 --> 00:11:41,320
new user signs U, an e-mail was 
attempted to be sent. 

245
00:11:41,880 --> 00:11:44,960
Now in your unit test, you don't
necessarily care if the e-mail 

246
00:11:44,960 --> 00:11:47,160
actually reached the users 
inbox. 

247
00:11:47,360 --> 00:11:49,840
That's a different kind of test.
You just want to know that your 

248
00:11:49,840 --> 00:11:53,200
sign up service correctly called
the send method on whatever 

249
00:11:53,200 --> 00:11:55,240
Mailer dependency uses. 
Got it. 

250
00:11:55,520 --> 00:11:56,960
Just checking the collaboration 
happened. 

251
00:11:57,080 --> 00:11:58,640
Exactly. 
So you'd use something like 

252
00:11:59,000 --> 00:12:03,000
verify m.sendanystring where M 
is your mock Mailer. 

253
00:12:03,520 --> 00:12:06,000
This line functions much like an
assertion, like checking if a 

254
00:12:06,000 --> 00:12:09,320
value is true, but instead of 
checking a return value, it 

255
00:12:09,320 --> 00:12:10,720
checks if a certain event 
occurred. 

256
00:12:11,440 --> 00:12:13,800
In this case, was the send 
method of the mock Mailer 

257
00:12:13,800 --> 00:12:16,760
executed at least once with any 
kind of spring argument. 

258
00:12:17,120 --> 00:12:19,400
It confirms that specific 
interaction took place. 

259
00:12:19,640 --> 00:12:21,760
That's a really powerful tool. 
Then it gives you a whole 

260
00:12:21,760 --> 00:12:24,080
different dimension to what you 
can actually verify in your 

261
00:12:24,080 --> 00:12:26,960
tests. 
So what does this all mean for 

262
00:12:26,960 --> 00:12:29,240
us? 
Broadly, it sounds like mocks 

263
00:12:29,240 --> 00:12:31,400
and stubs, even with their 
nuances, are just part of a 

264
00:12:31,400 --> 00:12:34,040
bigger family of testing tools. 
Precisely. 

265
00:12:34,360 --> 00:12:35,520
That's a great way to think 
about it. 

266
00:12:36,360 --> 00:12:39,920
Mocks and stubs are indeed 
considered special cases within 

267
00:12:39,920 --> 00:12:43,440
a broader category known 
collectively as test double S 

268
00:12:43,800 --> 00:12:45,920
the term test double. 
It's an umbrella term. 

269
00:12:46,360 --> 00:12:49,640
It covers any kind of object 
that stands in for a real object

270
00:12:49,640 --> 00:12:53,320
during a test, much like a stunt
double stands in for an actor in

271
00:12:53,320 --> 00:12:55,600
a movie. 
OK, test double S makes sense. 

272
00:12:55,600 --> 00:12:57,000
What other kinds are there? 
Well. 

273
00:12:57,000 --> 00:13:00,520
Our source clarifies two other 
significant types of test double

274
00:13:00,520 --> 00:13:03,080
S, each with its own specific 
use case. 

275
00:13:03,520 --> 00:13:06,120
First, you have dummy objects. 
These are really the simplest 

276
00:13:06,120 --> 00:13:08,040
form. 
They typically get passed as 

277
00:13:08,040 --> 00:13:11,040
arguments to a method, maybe in 
a constructor call, but they 

278
00:13:11,040 --> 00:13:13,320
aren't actually used within the 
methods body during that 

279
00:13:13,320 --> 00:13:15,040
specific test you're running. 
So they're just. 

280
00:13:15,440 --> 00:13:18,400
Essentially, yes. 
Their main purpose is simply to 

281
00:13:18,400 --> 00:13:21,400
satisfy the languages type 
system so you don't get 

282
00:13:21,400 --> 00:13:24,400
compilation errors. 
Imagine a method or a 

283
00:13:24,400 --> 00:13:28,240
constructor that requires, say, 
5 arguments, but for the 

284
00:13:28,240 --> 00:13:31,000
specific behavior you're testing
right now, you only actually 

285
00:13:31,000 --> 00:13:32,640
care about what happens with two
of them. 

286
00:13:33,400 --> 00:13:36,280
Dummy objects fill in the other 
three spots just so the code 

287
00:13:36,280 --> 00:13:38,920
compiles and runs. 
They satisfy the method 

288
00:13:38,920 --> 00:13:42,080
signature even though they don't
play an active role in the test 

289
00:13:42,080 --> 00:13:43,800
logic itself. 
OK, simple enough. 

290
00:13:43,920 --> 00:13:46,880
What's the other type? 
The other key type mentioned is 

291
00:13:46,880 --> 00:13:48,920
fake objects. 
Now, these are different from 

292
00:13:48,920 --> 00:13:51,000
mocks. 
Unlike a mock, which you 

293
00:13:51,000 --> 00:13:54,680
configure to respond in specific
ways to specific calls, a fake 

294
00:13:54,680 --> 00:13:59,000
object actually has a simpler 
but real working implementation 

295
00:13:59,000 --> 00:14:02,320
of the object it replaces. 
So it actually does something. 

296
00:14:02,320 --> 00:14:04,920
It's not just responding based 
on pre programmed rules. 

297
00:14:05,280 --> 00:14:06,760
Exactly. 
It's still a stand in. 

298
00:14:06,840 --> 00:14:09,680
It's not the production object, 
but it has its own working 

299
00:14:09,680 --> 00:14:12,160
logic, usually simplified for 
testing purposes. 

300
00:14:12,880 --> 00:14:16,000
A really common and very useful 
example is an in memory 

301
00:14:16,000 --> 00:14:18,520
database. 
Instead of your test connecting 

302
00:14:18,520 --> 00:14:22,440
to a slow external persistent 
database like Postgres or MySQL,

303
00:14:22,960 --> 00:14:26,160
a fake in memory database like 
H2 in the Java world for 

304
00:14:26,160 --> 00:14:29,840
example, can genuinely store and
retrieve data during your test. 

305
00:14:30,240 --> 00:14:33,600
It performs real database like 
operations, inserts, queries, 

306
00:14:33,600 --> 00:14:36,520
updates, but it does it all 
entirely in the computer's 

307
00:14:36,520 --> 00:14:38,800
memory and all the data 
disappears as soon as the test 

308
00:14:38,800 --> 00:14:40,800
finishes. 
Right, so you database like 

309
00:14:40,800 --> 00:14:43,040
behavior but super fast. 
Precisely. 

310
00:14:43,320 --> 00:14:46,120
This allows for incredibly fast 
tests that feel closer to 

311
00:14:46,120 --> 00:14:49,160
integration tests because real 
logic is executing, but without 

312
00:14:49,160 --> 00:14:52,160
the setup complexity and 
slowness of using a full real 

313
00:14:52,160 --> 00:14:55,800
database system. 
Wow, OK, so dummies, fakes, 

314
00:14:55,800 --> 00:14:59,640
stubs, mocks. 
This really gives you, our 

315
00:14:59,640 --> 00:15:02,040
listener, a much more 
comprehensive map, doesn't it? 

316
00:15:02,320 --> 00:15:05,560
A whole toolkit for different 
testing situations, knowing 

317
00:15:05,560 --> 00:15:07,920
these distinctions. 
Dummy, fake, stub, mock. 

318
00:15:07,920 --> 00:15:10,520
It helps you navigate those 
technical conversations, 

319
00:15:10,800 --> 00:15:13,320
understand documentation better,
maybe even articles or blog 

320
00:15:13,320 --> 00:15:15,840
posts you read. 
And ultimately, it empowers you 

321
00:15:15,840 --> 00:15:18,960
to choose the right kind of test
double for the specific testing 

322
00:15:18,960 --> 00:15:22,520
job you need to do, leading to 
better, more reliable software. 

323
00:15:22,840 --> 00:15:26,680
What an insightful deep dive. 
We've really unpacked how these 

324
00:15:26,680 --> 00:15:30,320
mock frameworks, like Makito 
genuinely streamline the 

325
00:15:30,320 --> 00:15:32,760
creation and configuration of 
mock objects. 

326
00:15:33,000 --> 00:15:35,880
It saves developers just immense
amounts of time and effort in 

327
00:15:35,880 --> 00:15:39,280
unit testing, fostering those 
rapid feedback cycles we talked 

328
00:15:39,280 --> 00:15:41,000
about. 
Absolutely, and we've explored 

329
00:15:41,000 --> 00:15:43,320
those sometimes subtle but 
important distinctions between 

330
00:15:43,320 --> 00:15:44,960
the different types of test 
double s, from the simple 

331
00:15:44,960 --> 00:15:48,160
dummies through fakes, stubs and
the interaction focused mocks. 

332
00:15:48,280 --> 00:15:50,360
Hopefully provides A clearer, 
more nuanced picture of how 

333
00:15:50,360 --> 00:15:53,200
developers effectively isolate 
and test specific units of code,

334
00:15:53,400 --> 00:15:56,440
ensuring both correctness and, 
crucially, inability overtime. 

335
00:15:56,680 --> 00:15:59,120
Thank you so much for joining us
on this deep dive. 

336
00:15:59,240 --> 00:16:03,120
We really hope this exploration 
has given you a useful shortcut 

337
00:16:03,120 --> 00:16:06,240
to being well informed on mocks 
and test double S.