1
00:00:00,000 --> 00:00:04,200
The main goal of unit testing is
enabling sustainable. 

2
00:00:04,200 --> 00:00:08,300
Growth of your software project.
This is the main goal because as

3
00:00:08,300 --> 00:00:12,700
the project grows the amount of 
code in that project increases 

4
00:00:12,700 --> 00:00:17,000
and with a it increases, the 
surface area for potential box 

5
00:00:17,000 --> 00:00:19,300
in that code. 
So basically the more could you 

6
00:00:19,300 --> 00:00:23,000
write the more probability there
is that you introduce a buck in 

7
00:00:23,000 --> 00:00:27,800
that code unit tests, help you 
to avoid this situation so you 

8
00:00:27,800 --> 00:00:29,800
don't introduce any regressions 
in those. 

9
00:00:30,000 --> 00:00:34,400
Features and also they allow you
to refactor your code more 

10
00:00:34,400 --> 00:00:37,100
freely because you're not afraid
of doing that. 

11
00:00:37,100 --> 00:00:40,100
So you're able to maintain the 
quality of your code. 

12
00:00:40,200 --> 00:00:44,200
And therefore you're able to 
move faster Glitz more quality. 

13
00:00:44,200 --> 00:00:50,500
Cool piece. 
Hey everyone. 

14
00:00:51,000 --> 00:00:55,900
My name is Henry Surya be Robin.
And you're listening to the 

15
00:00:55,900 --> 00:00:58,900
tekhelet journal. 
The show will be bringing you 

16
00:00:58,900 --> 00:01:02,300
the greatest technical leaders 
practitioners and thought 

17
00:01:02,300 --> 00:01:05,700
leaders in the industry to 
discuss about their Journey 

18
00:01:06,000 --> 00:01:10,300
ideas and practices that we all 
can learn and apply to build a 

19
00:01:10,300 --> 00:01:13,900
highly performing technical team
and to make an impact in your 

20
00:01:13,900 --> 00:01:17,600
personal work. 
So let's dive into our Journal. 

21
00:01:22,900 --> 00:01:25,500
Hello, everyone. 
Welcome to another episode of 

22
00:01:25,500 --> 00:01:28,800
the tekhelet journal podcast. 
Thank you for tuning in and 

23
00:01:28,800 --> 00:01:31,600
spending your time with me 
today, listening to this 

24
00:01:31,600 --> 00:01:34,500
episode. 
If you haven't, please follow 

25
00:01:34,500 --> 00:01:37,600
technology, you know on your 
podcast app and social media 

26
00:01:37,600 --> 00:01:41,900
channels on LinkedIn Twitter and
Instagram, and if you have been 

27
00:01:41,900 --> 00:01:45,200
enjoying this podcast, consider 
supporting the show by 

28
00:01:45,200 --> 00:01:49,800
subscribing at technology, no, 
dot f /, Patron, and support me 

29
00:01:49,800 --> 00:01:52,500
to continue producing, great 
content every week. 

30
00:01:53,500 --> 00:01:56,700
Unit testing, as a software 
development, best practice has 

31
00:01:56,700 --> 00:02:00,400
been around for a long time 
despite the history of it and 

32
00:02:00,400 --> 00:02:03,400
the major benefits, that unit 
testing brings from my own 

33
00:02:03,400 --> 00:02:05,300
experience. 
I still witness. 

34
00:02:05,300 --> 00:02:08,000
There are still many software 
Engineers who do not understand 

35
00:02:08,000 --> 00:02:11,000
the concept, and even for some 
who understand it. 

36
00:02:11,100 --> 00:02:14,000
They do not practice it in their
day-to-day software development 

37
00:02:14,000 --> 00:02:16,500
work. 
Another thing that I observe 

38
00:02:16,500 --> 00:02:19,900
from my own experience is unit, 
testing that is not done, 

39
00:02:19,900 --> 00:02:22,800
optimally ranging from flaky 
tests. 

40
00:02:23,300 --> 00:02:26,900
Sometimes pass or sometimes fail
randomly that normally just 

41
00:02:26,900 --> 00:02:31,000
require a rerun brittle, test 
test that easily break. 

42
00:02:31,100 --> 00:02:34,600
Every time we make any changes 
to the code under test test 

43
00:02:34,600 --> 00:02:38,300
without any assertion or unit 
test code coverage that has to 

44
00:02:38,300 --> 00:02:41,600
be mandated from the top of the 
organization that could 

45
00:02:41,600 --> 00:02:45,600
introduce wrong incentives and 
culture in order to spread more 

46
00:02:45,600 --> 00:02:49,100
knowledge about unit testing and
its best practices for today's 

47
00:02:49,100 --> 00:02:50,700
episode. 
I'm happy to share my 

48
00:02:50,700 --> 00:02:53,100
conversation with Vladimir 
korotkov. 

49
00:02:53,900 --> 00:02:58,000
Vladimir is the author of unit, 
testing principles practices and

50
00:02:58,000 --> 00:03:02,800
patterns and the founder of 
Enterprise craftsmanship blog in

51
00:03:02,800 --> 00:03:06,200
this episode Vladimir. 
And I discussed in depth about 

52
00:03:06,200 --> 00:03:10,100
unit testing Vladimir broke down
the four pillars of unit. 

53
00:03:10,100 --> 00:03:13,500
Testing a very important 
principles that I find very 

54
00:03:13,500 --> 00:03:16,800
insightful to a deer. 
For our unit testing practices 

55
00:03:17,300 --> 00:03:21,000
and also the anatomy of a good 
unit tests as well as mentioned 

56
00:03:21,100 --> 00:03:23,100
a couple of common unit. 
Testing & Repair. 

57
00:03:23,300 --> 00:03:27,500
And we also discussed topics 
such as test-driven development 

58
00:03:27,800 --> 00:03:31,900
code coverage, and other unit 
testing metrics past, mocking 

59
00:03:31,900 --> 00:03:35,000
and how to use it properly. 
And how we can be more 

60
00:03:35,000 --> 00:03:37,300
pragmatic. 
When writing unit tests. 

61
00:03:38,000 --> 00:03:41,400
I really enjoyed my conversation
with Vladimir discussing many 

62
00:03:41,400 --> 00:03:44,000
things about unit, testing, 
clarifying, common 

63
00:03:44,000 --> 00:03:47,200
misconceptions and anti 
patterns, and improving my own 

64
00:03:47,200 --> 00:03:50,700
understanding of unit testing, 
and I hope you will find some 

65
00:03:50,700 --> 00:03:53,100
unit testing insights from this 
episodes as well. 

66
00:03:53,200 --> 00:03:57,000
L consider helping the show by 
living it, a rating and review 

67
00:03:57,000 --> 00:04:00,400
on your podcast app or comments 
on the social media channels, 

68
00:04:01,000 --> 00:04:03,600
those reviews and comments are 
one of the best ways to help me 

69
00:04:03,600 --> 00:04:07,400
get this podcast to reach more 
listeners and hopefully, they 

70
00:04:07,400 --> 00:04:10,800
will also benefit from all the 
contents in this podcast. 

71
00:04:11,200 --> 00:04:14,200
Let's go to our episode right 
after our sponsor message. 

72
00:04:14,500 --> 00:04:16,500
Are you looking for a new cool 
swag? 

73
00:04:16,800 --> 00:04:19,399
Taglit Journal. 
Now, offers you some swags that 

74
00:04:19,399 --> 00:04:23,100
you can purchase online? 
These wax are printed on demand.

75
00:04:23,300 --> 00:04:26,600
Based on your preference and 
will be delivered safely to you 

76
00:04:26,600 --> 00:04:29,200
all over the world where 
shipping is available. 

77
00:04:29,600 --> 00:04:32,200
Check out all the cool swag is 
available by visiting 

78
00:04:32,200 --> 00:04:35,600
technology, you know dot, f / 
shop and don't forget to break 

79
00:04:35,600 --> 00:04:37,800
yourself. 
Once you receive any of those 

80
00:04:37,800 --> 00:04:42,500
tracks. 
Hello everyone, welcome back to 

81
00:04:42,500 --> 00:04:45,300
another new episode of the pack 
leader of podcast. 

82
00:04:45,500 --> 00:04:46,700
Today. 
I have a guest with me. 

83
00:04:46,700 --> 00:04:48,700
His name is Vladimir Corey 
cough. 

84
00:04:49,300 --> 00:04:50,800
He's the author of the book 
unit. 

85
00:04:50,800 --> 00:04:53,900
Testing principles practices and
Patterns. 

86
00:04:54,100 --> 00:04:57,500
So today we'll be talking about 
unit testing and how to do a 

87
00:04:57,500 --> 00:05:00,800
unit testing of the best 
practices tips and tricks. 

88
00:05:00,800 --> 00:05:04,000
And what you need to do in order
to come up with a good code 

89
00:05:04,000 --> 00:05:07,700
coverage for your software. 
Interestingly, bloody made also 

90
00:05:07,700 --> 00:05:10,100
is a popular author in plural 
site. 

91
00:05:10,100 --> 00:05:13,700
So if you look at his profile in
plural site, you'll see a number

92
00:05:13,700 --> 00:05:17,200
of courses that he has done over
the number of years, including 

93
00:05:17,200 --> 00:05:20,200
topics like domain driven 
design, cqrs some C sharp 

94
00:05:20,200 --> 00:05:24,300
courses and things like that, so
really, The top a lot about 

95
00:05:24,300 --> 00:05:27,400
software best practices with you
today in particular about any 

96
00:05:27,400 --> 00:05:29,500
testing Vladimir. 
Welcome to the show. 

97
00:05:30,400 --> 00:05:32,900
Thank you. 
I thank you for having me so 

98
00:05:32,900 --> 00:05:35,500
that they may be in the 
beginning for people to know 

99
00:05:35,500 --> 00:05:36,300
more about. 
You. 

100
00:05:36,400 --> 00:05:39,000
Could, you introduce yourself 
may be telling you more about 

101
00:05:39,000 --> 00:05:41,600
your career Journey or 
highlights and turning points? 

102
00:05:42,300 --> 00:05:44,500
Sure. 
So, if we start from the first 

103
00:05:44,500 --> 00:05:50,500
beginning, I started to program 
professionally and 2005 about 

104
00:05:50,500 --> 00:05:55,600
seven years ago, I moved from 
Russia to the US and about that 

105
00:05:55,600 --> 00:05:58,500
same time. 
I started blogging at Enterprise

106
00:05:58,500 --> 00:06:02,100
craftsmanship.com. 
So that was one of the turning 

107
00:06:02,100 --> 00:06:04,900
points in my career. 
By that time. 

108
00:06:04,900 --> 00:06:09,200
I was already pretty established
as a professional programmer, 

109
00:06:09,500 --> 00:06:14,600
but writing on my blog, forced 
me to learn even more than I did

110
00:06:14,600 --> 00:06:17,100
before. 
So, to put my thoughts down, I 

111
00:06:17,100 --> 00:06:20,700
had to basically learn much more
than before in other add turning

112
00:06:20,700 --> 00:06:24,500
point. 
For me, was when I Indeed, joint

113
00:06:24,500 --> 00:06:28,200
pluralsight. 
I did an audition with them. 

114
00:06:28,200 --> 00:06:32,800
They liked my test course, so to
speak and they accepted me as an

115
00:06:32,800 --> 00:06:37,200
author on the platform since 
then I created several courses 

116
00:06:37,200 --> 00:06:39,500
about wealth or something like 
that. 

117
00:06:39,700 --> 00:06:42,500
A lot of them were as you 
mentioned about domain-driven 

118
00:06:42,500 --> 00:06:45,100
design. 
They also authored a learning 

119
00:06:45,100 --> 00:06:48,900
path with the same subject. 
Most of the courses in that 

120
00:06:49,000 --> 00:06:52,500
learning paths, our mind about 
the main models, cqrs, and so 

121
00:06:52,500 --> 00:06:54,500
on. 
The couple years ago. 

122
00:06:54,500 --> 00:06:59,300
I also started to think about 
writing a book, the two topics 

123
00:06:59,300 --> 00:07:03,900
that were the closest to me or 
about the moon giving design and

124
00:07:03,900 --> 00:07:07,200
also about unit testing. 
So, these are the topics that I 

125
00:07:07,200 --> 00:07:10,900
enjoyed the most. 
So I thought that maybe I could 

126
00:07:10,900 --> 00:07:13,300
write a book on one of these 
subjects. 

127
00:07:13,800 --> 00:07:18,400
I thought about DDD for a while 
about the mentoring design, but 

128
00:07:18,400 --> 00:07:22,100
I decided not to write a book on
that topic, because although I 

129
00:07:22,100 --> 00:07:25,500
think people, Like my horses 
about them into design. 

130
00:07:25,700 --> 00:07:29,900
I don't really think that I have
a lot of new stuff to say, on 

131
00:07:29,900 --> 00:07:32,400
that topic. 
There are quite a few of good 

132
00:07:32,400 --> 00:07:35,100
books already on the market that
covered all. 

133
00:07:35,100 --> 00:07:39,400
Or most of the stuff that I 
teach on puerile site about the 

134
00:07:39,400 --> 00:07:42,700
Mandarin Zayn and so I decided 
not to write about that. 

135
00:07:42,900 --> 00:07:47,000
But with regards to unit, 
testing this situation here was 

136
00:07:47,000 --> 00:07:49,800
different. 
So there were quite a few books 

137
00:07:49,800 --> 00:07:53,000
already but the walleye the 
targeted. 

138
00:07:53,100 --> 00:07:57,100
Beginners, they didn't basically
teach it the material that I 

139
00:07:57,100 --> 00:07:59,200
wanted to teach about unit 
testing. 

140
00:07:59,500 --> 00:08:03,300
So basically, there wasn't a 
comprehensive material for 

141
00:08:03,300 --> 00:08:06,700
people who are not beginners, 
who already mastered the 

142
00:08:06,700 --> 00:08:10,500
foundation walls, and who wanted
to take the next step towards 

143
00:08:10,500 --> 00:08:14,400
intermediate, or advanced level.
And for those people, there 

144
00:08:14,400 --> 00:08:16,800
weren't a lot of materials on 
the web. 

145
00:08:17,000 --> 00:08:21,400
So I decided to write my own 
book on that topic, so, it's 

146
00:08:21,400 --> 00:08:24,000
been a pleasure to talk about, 
you know, Testing in particular,

147
00:08:24,000 --> 00:08:27,200
especially for you who have been
around in the industry for so 

148
00:08:27,200 --> 00:08:30,200
long and also have practice. 
A lot of things about these 

149
00:08:30,200 --> 00:08:33,299
software best practices. 
So in the beginning, maybe we 

150
00:08:33,299 --> 00:08:35,799
can recap a little bit. 
What do you think is the 

151
00:08:35,799 --> 00:08:41,000
definition of unit tests there? 
I think two definitions that are

152
00:08:41,000 --> 00:08:44,700
applicable here. 
One has some more high level and

153
00:08:44,700 --> 00:08:49,100
the other one is more low level.
So the high level definition is 

154
00:08:49,100 --> 00:08:52,500
that you can say that a unit 
test is any task. 

155
00:08:52,500 --> 00:08:55,300
That is real. 
Eaten by developers by the same.

156
00:08:55,300 --> 00:08:59,300
People who write the coat that 
is covered by a dose unit tests.

157
00:08:59,600 --> 00:09:04,000
More, low-level definition would
be something like a unicast is 

158
00:09:04,000 --> 00:09:08,100
an automated tasks, that covers 
a single unit of behavior. 

159
00:09:08,400 --> 00:09:12,500
It does it quite fast quickly. 
And also it does it in 

160
00:09:12,500 --> 00:09:14,500
isolation, from other unit 
tests. 

161
00:09:14,700 --> 00:09:18,000
So these are the three 
properties of unit test. 

162
00:09:18,200 --> 00:09:21,100
If an automated past, doesn't 
meet any of these three 

163
00:09:21,100 --> 00:09:23,000
properties, then it's not the 
unit. 

164
00:09:23,200 --> 00:09:27,900
Asked it's an integration test. 
And then if we go hire them as 

165
00:09:27,900 --> 00:09:31,000
pyramid, there are also 
end-to-end tests or functional 

166
00:09:31,000 --> 00:09:33,300
pants or whatever. 
You may call them. 

167
00:09:33,600 --> 00:09:37,800
Those are a subset of 
integration tests and the line 

168
00:09:37,800 --> 00:09:39,800
between let's say end-to-end 
tests. 

169
00:09:39,800 --> 00:09:44,300
And integration tests is much 
more blurry than between unit 

170
00:09:44,300 --> 00:09:48,000
tests and integration tests. 
But even the line between unit 

171
00:09:48,000 --> 00:09:50,600
tests and integration tests is 
not as clear. 

172
00:09:50,600 --> 00:09:55,300
And so, sometimes I just put 
Both unit tests and integration 

173
00:09:55,300 --> 00:09:59,100
tests and even end-to-end tests 
into the whole bucket of unit 

174
00:09:59,100 --> 00:10:01,600
tests. 
So tests that are written by 

175
00:10:01,600 --> 00:10:05,500
developers themselves. 
So, speaking about unit tests 

176
00:10:05,500 --> 00:10:08,500
versus integration tests. 
I know they are always this long

177
00:10:08,500 --> 00:10:10,800
debate about the, you really 
need unit tests. 

178
00:10:10,800 --> 00:10:12,600
Can we just do integration 
tests? 

179
00:10:13,000 --> 00:10:15,100
What do you think about this 
argument? 

180
00:10:15,900 --> 00:10:18,700
Yeah. 
This is an understandable point.

181
00:10:18,900 --> 00:10:22,000
I would say that I disagree with
that point, but it is 

182
00:10:22,000 --> 00:10:23,900
understandable. 
Comes from. 

183
00:10:24,000 --> 00:10:28,000
So I would say that people who 
argue against unit tests. 

184
00:10:28,000 --> 00:10:31,200
If we were all feet aggression 
tests, only argue from the 

185
00:10:31,200 --> 00:10:34,900
standpoint of their unit tests 
being too low value. 

186
00:10:34,900 --> 00:10:39,900
So they are not valuable enough 
to keep around in the project 

187
00:10:39,900 --> 00:10:42,300
they fail with each refract 
from. 

188
00:10:42,300 --> 00:10:45,400
So they are fragile. 
They are brittle and they don't 

189
00:10:45,400 --> 00:10:48,400
introduce a lot of protection 
against potential box. 

190
00:10:48,700 --> 00:10:52,900
And so, from that perspective, I
understand why they would say so

191
00:10:53,100 --> 00:10:56,500
Integration tests on the other 
hand, they can be more valuable 

192
00:10:56,500 --> 00:10:59,400
because they cover a larger 
slice of cold. 

193
00:10:59,500 --> 00:11:03,200
They have a higher probability 
of catching a regression a book 

194
00:11:03,300 --> 00:11:06,900
and they also tend to feel less 
frequently. 

195
00:11:07,100 --> 00:11:11,200
They tend to produce less false 
positives, false alarms to that 

196
00:11:11,200 --> 00:11:13,700
point. 
I would say that it just means 

197
00:11:13,700 --> 00:11:16,300
that you don't write unit tests 
properly. 

198
00:11:16,500 --> 00:11:20,700
You're probably writing them in 
a way that makes them brittle. 

199
00:11:20,900 --> 00:11:23,000
And in a way that doesn't 
provide. 

200
00:11:23,100 --> 00:11:27,300
You lot of overall paleo. 
The better approach here is not 

201
00:11:27,300 --> 00:11:31,300
to get rid of unit tests all 
together but instead refactor, 

202
00:11:31,300 --> 00:11:33,700
your unit tests and make them 
more valuable. 

203
00:11:33,700 --> 00:11:37,900
So maybe if you approach to the 
argument of unit tests, maybe 

204
00:11:37,900 --> 00:11:41,300
can you define some of the 
benefits of goals of actually 

205
00:11:41,300 --> 00:11:44,400
writing unit tests, especially 
for developers who are still not

206
00:11:44,400 --> 00:11:49,100
yet into unit past practices. 
The main goal of unit. 

207
00:11:49,100 --> 00:11:52,700
Testing is enabling sustainable 
growth of your software. 

208
00:11:53,100 --> 00:11:57,800
Eject, this is the main goal 
because as the project grows the

209
00:11:57,800 --> 00:12:01,100
amount of code in that project 
increases and we the it 

210
00:12:01,100 --> 00:12:05,300
increases the surface area for 
potential box in that code. 

211
00:12:05,400 --> 00:12:08,400
So basically the more could you 
write the more probability of 

212
00:12:08,400 --> 00:12:12,400
there is that you introduced a 
bug in that code that in turn 

213
00:12:12,400 --> 00:12:16,800
leads to a situation where you 
or lease a lot of box with each 

214
00:12:16,800 --> 00:12:20,800
deployment to production or you 
spend so much time when you look

215
00:12:20,800 --> 00:12:25,000
testing that release that 
Time-to-market metric, suffers 

216
00:12:25,000 --> 00:12:28,300
drastically, unit tests. 
Help you to avoid this 

217
00:12:28,300 --> 00:12:31,000
situation. 
They act as a safety net. 

218
00:12:31,000 --> 00:12:34,100
That ensures that when you 
introduce new features in your 

219
00:12:34,100 --> 00:12:36,900
software, the old features stay 
operational. 

220
00:12:36,900 --> 00:12:39,900
So, you don't introduce any 
regressions in those features, 

221
00:12:40,200 --> 00:12:44,500
and also, they allow you to 
refactor your code more freely 

222
00:12:44,700 --> 00:12:46,600
because you're not afraid of 
doing that. 

223
00:12:46,600 --> 00:12:49,600
So, you're able to maintain the 
quality of your code. 

224
00:12:49,600 --> 00:12:52,900
And therefore you're able to 
move faster Glitz me. 

225
00:12:53,000 --> 00:12:56,200
More quality. 
Cool piece, spaghetti about unit

226
00:12:56,200 --> 00:12:57,000
test. 
A lot of people. 

227
00:12:57,000 --> 00:13:00,500
Also associate that b PD like 
tests pass, or is it like 

228
00:13:00,500 --> 00:13:03,300
production could first? 
Do you have any flavor around? 

229
00:13:03,300 --> 00:13:07,700
Which one do you think is best 
test first versus test last 

230
00:13:07,700 --> 00:13:11,800
verses cooled, first approaches.
I didn't cover it in the book. 

231
00:13:12,000 --> 00:13:14,600
But yeah, I do have some 
opinions on that. 

232
00:13:14,700 --> 00:13:18,400
So I do believe that tdd 
test-driven development or test.

233
00:13:18,400 --> 00:13:22,700
First approach is where you 
belong, but you need to apply it

234
00:13:22,700 --> 00:13:24,900
in the Right moment of your 
project. 

235
00:13:25,100 --> 00:13:28,500
I would say the general 
guideline here would be that 

236
00:13:28,500 --> 00:13:30,900
when you just start with the 
project. 

237
00:13:30,900 --> 00:13:33,400
When you don't have enough 
information of what you're 

238
00:13:33,400 --> 00:13:37,200
doing, or how your main model 
would look, or how your project 

239
00:13:37,200 --> 00:13:40,900
would be structured. 
This is not a good time to apply

240
00:13:40,900 --> 00:13:45,400
test-driven development because 
here you are in the mood of 

241
00:13:45,400 --> 00:13:49,000
exploring, your problem domain, 
exploring your possible 

242
00:13:49,000 --> 00:13:51,500
solutions. 
And here are your tests will 

243
00:13:51,500 --> 00:13:54,500
only drag you down. 
At this stage, I would recommend

244
00:13:54,500 --> 00:13:57,500
to do some outlining some 
prototyping. 

245
00:13:57,700 --> 00:14:01,700
When you are comfortable enough 
with your problem domain, and 

246
00:14:01,700 --> 00:14:04,800
you're pretty sure that the way 
you are implementing. 

247
00:14:04,800 --> 00:14:08,800
Your domain model is to be, 
you're going to move with moving

248
00:14:08,800 --> 00:14:12,300
forward when you're sure about 
that, Dan, you can apply the 

249
00:14:12,300 --> 00:14:16,200
test driven development 
approach, start with tests. 

250
00:14:16,200 --> 00:14:20,400
And then basically in forward to
it, this approach that during 

251
00:14:20,400 --> 00:14:24,000
development is especially useful
when you all Do you have some 

252
00:14:24,000 --> 00:14:28,200
code base? 
And even a test suite and you 

253
00:14:28,200 --> 00:14:32,300
need to, let's say fix umbach. 
This is where the test driven 

254
00:14:32,300 --> 00:14:36,400
development approach shrines 
because you are able to first 

255
00:14:36,500 --> 00:14:41,200
put a test that reproduces, it 
the Box itself and then fix the 

256
00:14:41,200 --> 00:14:44,500
BOK this way. 
Your are sure that your test is 

257
00:14:44,500 --> 00:14:46,900
correct. 
Because you saw that this just 

258
00:14:46,900 --> 00:14:50,200
feels for good reason because 
there is a bug in your code base

259
00:14:50,400 --> 00:14:54,500
and then fix the park and then 
make your Test pass basically 

260
00:14:54,500 --> 00:14:57,700
test-driven development. 
Solves two problems. 

261
00:14:57,900 --> 00:15:02,800
It allows you to check that your
test itself is correct. 

262
00:15:02,900 --> 00:15:05,500
I would say it allows you to do 
that more easily because we've 

263
00:15:05,500 --> 00:15:08,800
cooled first approach. 
You still can do that, but it's 

264
00:15:08,800 --> 00:15:12,600
just a little bit harder to do 
because when you write your code

265
00:15:12,600 --> 00:15:16,600
first and then you write your 
tests in order to past that past

266
00:15:16,800 --> 00:15:20,300
you have to modify your coat 
back into incorrect. 

267
00:15:20,300 --> 00:15:24,300
One to see that your test fails 
first and And you modify back 

268
00:15:24,300 --> 00:15:26,300
and see. 
Then the test started to pass. 

269
00:15:26,600 --> 00:15:30,600
So with test-driven development 
with test, first approach, you 

270
00:15:30,600 --> 00:15:34,000
avoid these unnecessary stamp 
because you write your test. 

271
00:15:34,000 --> 00:15:38,000
First ensure that it fails for 
good reason, and only Dan you 

272
00:15:38,000 --> 00:15:42,000
fix that past, and make it pass.
So yeah, that's the first 

273
00:15:42,000 --> 00:15:45,500
benefit of T DT. 
Is that it helps you to check 

274
00:15:45,500 --> 00:15:49,400
your tests more easily. 
The second benefit of T DT, is 

275
00:15:49,400 --> 00:15:52,900
that it helps you structure your
development process. 

276
00:15:53,000 --> 00:15:55,500
Process. 
When you have a specific goal in

277
00:15:55,500 --> 00:15:59,700
mind, he can introduce a high 
level test that checks the 

278
00:15:59,700 --> 00:16:04,000
specific functionality. 
And then, you can also introduce

279
00:16:04,000 --> 00:16:07,500
lower level test unit tests, 
when you implement specific 

280
00:16:07,500 --> 00:16:10,900
pieces of that functionality and
so, it provides some structure. 

281
00:16:11,200 --> 00:16:13,700
So get that's in the second 
benefit of test-driven 

282
00:16:13,700 --> 00:16:18,400
development, but even without 
tdd, you will capture a lot of 

283
00:16:18,400 --> 00:16:20,500
benefits. 
If you just apply UD testing, 

284
00:16:20,700 --> 00:16:23,700
even if you write unit tests 
after your Your coat. 

285
00:16:24,500 --> 00:16:26,200
Thanks for highlighting all 
these benefits. 

286
00:16:26,400 --> 00:16:29,000
I also learn from other people, 
and also from my experience. 

287
00:16:29,000 --> 00:16:32,100
Sometimes the tests pass 
approach could actually lead to 

288
00:16:32,100 --> 00:16:35,600
better design, simply because 
you think from the perspective 

289
00:16:35,600 --> 00:16:38,900
of the client, or the user of 
your production code, and then 

290
00:16:38,900 --> 00:16:41,500
you come with the task force, 
which then leads you to a better

291
00:16:41,500 --> 00:16:45,000
design, maybe more testability 
in mind, and things like that. 

292
00:16:45,300 --> 00:16:47,400
Do you have any thought around 
test drive? 

293
00:16:47,400 --> 00:16:52,000
See that the design? 
Well, I would say, testing the 

294
00:16:52,000 --> 00:16:56,800
ability at to test your called 
ears and necessary but not 

295
00:16:56,900 --> 00:17:00,700
sufficient requirement for good 
quote design because I would say

296
00:17:00,700 --> 00:17:04,700
that it's a good - indicator but
it's a bad positive. 

297
00:17:04,700 --> 00:17:08,500
One when you're cold, doesn't 
allow you to easily passed that 

298
00:17:08,500 --> 00:17:10,200
code? 
Then it's a good sign that 

299
00:17:10,200 --> 00:17:11,700
there's something wrong with 
that coat. 

300
00:17:11,900 --> 00:17:14,800
It structured thing correctly. 
Maybe you didn't Implement 

301
00:17:14,800 --> 00:17:18,599
dependence injection properly or
something like that, but even if

302
00:17:18,599 --> 00:17:23,200
you are able To cover this code 
with unit tests or with 

303
00:17:23,200 --> 00:17:27,599
integration tests, even then 
it's not a 100% guarantee. 

304
00:17:27,599 --> 00:17:30,500
If they aren't your code itself 
is structured properly. 

305
00:17:30,700 --> 00:17:33,500
So, I would say that it does 
help with cool design. 

306
00:17:33,500 --> 00:17:37,300
But only partially, a lot of 
times when we write unit tests. 

307
00:17:37,300 --> 00:17:39,300
We associated with code 
coverage. 

308
00:17:39,600 --> 00:17:42,500
So almost, every time when 
someone is writing unit tests, 

309
00:17:42,500 --> 00:17:44,100
they will care about code 
coverage. 

310
00:17:44,300 --> 00:17:46,900
Maybe you can explain a little 
bit why the emphasis on code 

311
00:17:46,900 --> 00:17:50,500
coverage or if there are any 
other Successful Matrix for 

312
00:17:50,500 --> 00:17:54,200
people to use when they write 
unit tests, code, coverage shoes

313
00:17:54,300 --> 00:17:57,000
and very popular metric. 
Because it's may be the only 

314
00:17:57,000 --> 00:18:00,900
metric regarding unit tests that
you can apply automatically. 

315
00:18:01,100 --> 00:18:05,100
So you can use some to link that
will give you some specific 

316
00:18:05,100 --> 00:18:06,800
number and you can track that 
number. 

317
00:18:06,800 --> 00:18:10,600
So that's basically one of the 
reasons why people like this 

318
00:18:10,600 --> 00:18:13,200
metric. 
So much, in terms of its merits,

319
00:18:13,400 --> 00:18:16,700
I would say that I would apply 
the same framework here. 

320
00:18:16,900 --> 00:18:19,500
The same framework. 
As with the ability to test your

321
00:18:19,700 --> 00:18:23,800
Walt called coverage metrics are
also negative indicator, but 

322
00:18:23,800 --> 00:18:28,300
they are bad positive one. 
That's because if you have a low

323
00:18:28,300 --> 00:18:33,400
coverage number, let's say 
anything below 50 or 40 percent.

324
00:18:33,400 --> 00:18:36,100
That's a good indication that 
you don't test enough. 

325
00:18:36,300 --> 00:18:37,900
You don't have enough unit 
tests. 

326
00:18:38,100 --> 00:18:41,800
But even if you have a high 
coverage number ninety percent 

327
00:18:41,800 --> 00:18:45,900
or even 100%, it doesn't 
guarantee if that your tests are

328
00:18:45,900 --> 00:18:49,100
of good quality. 
You can still have tests that 

329
00:18:49,100 --> 00:18:51,700
Dawn. 
Don't properly test your code, a

330
00:18:51,700 --> 00:18:55,000
contrived example, here, would 
be assertion for unit. 

331
00:18:55,000 --> 00:18:57,600
Testing. 
It is when you right past sit 

332
00:18:57,600 --> 00:19:01,000
that execute your production 
code, but they don't assert 

333
00:19:01,000 --> 00:19:04,100
anything. 
This is a simple and easy way 

334
00:19:04,100 --> 00:19:08,400
for you to bump up your 
coverage, metrics up to 90 or 

335
00:19:08,400 --> 00:19:12,000
even 100%, without actually 
trying because those tests are 

336
00:19:12,400 --> 00:19:16,700
will, basically useless and they
will not feel and they don't 

337
00:19:16,700 --> 00:19:19,700
check anything. 
And you mentioned a little bit 

338
00:19:19,700 --> 00:19:22,800
about what you should aim for 
when you start with unit tests, 

339
00:19:22,800 --> 00:19:24,600
right? 
So there are three important 

340
00:19:24,600 --> 00:19:27,700
things that you cover their, 
which is that the test should be

341
00:19:27,700 --> 00:19:29,900
integrated with your development
cycle. 

342
00:19:30,200 --> 00:19:32,800
And then you should Target the 
most important parts of the code

343
00:19:32,800 --> 00:19:37,200
base and you should get maximum 
value with minimum maintenance 

344
00:19:37,200 --> 00:19:39,600
costs. 
If you want to explain more on 

345
00:19:39,600 --> 00:19:44,100
these three properties p.m. 
The only way to benefit from 

346
00:19:44,100 --> 00:19:48,900
test, is when you use those 
tests, this is why Why I put an 

347
00:19:48,900 --> 00:19:52,300
emphasis on that point, that you
should have those unit tests, 

348
00:19:52,300 --> 00:19:55,700
but integration tests as well, 
integrated into the development 

349
00:19:55,700 --> 00:19:58,400
cycle so that you run them as 
often as possible. 

350
00:19:58,600 --> 00:20:01,900
Ideally, you should run them 
after each called change, but of

351
00:20:01,900 --> 00:20:05,200
course, it is not always 
feasible, but it's the ideal and

352
00:20:05,200 --> 00:20:10,100
then your unit tests also should
Target the most important parts 

353
00:20:10,100 --> 00:20:13,900
of your code paste first because
not all your code base is 

354
00:20:13,900 --> 00:20:16,700
equally important. 
There are some parts that are 

355
00:20:16,700 --> 00:20:19,600
more important for the Checked. 
And there are some parts that 

356
00:20:19,600 --> 00:20:22,700
are less important. 
For example, business logic, or 

357
00:20:22,700 --> 00:20:26,000
the main model is at the most 
important part of your project. 

358
00:20:26,000 --> 00:20:28,500
And this is what you need to 
cover first. 

359
00:20:28,500 --> 00:20:32,400
When doing unit, testing some 
infrastructure codes are maybe 

360
00:20:32,400 --> 00:20:36,400
utility classes, the might be 
important, but they are usually 

361
00:20:36,400 --> 00:20:38,800
not as important as business 
logic. 

362
00:20:39,000 --> 00:20:42,700
And the third Point here is that
you shouldn't just write tests 

363
00:20:42,700 --> 00:20:46,300
for the sake of unit test. 
You should be pragmatic about it

364
00:20:46,400 --> 00:20:49,700
and you should email. 
At getting the maximum possible 

365
00:20:49,700 --> 00:20:53,200
value of those tests with the 
minimum maintenance costs. 

366
00:20:53,300 --> 00:20:58,000
That is what I cover in the rest
of this book because this is 

367
00:20:58,000 --> 00:21:02,000
easier said than done in the 
remaining of the book. 

368
00:21:02,000 --> 00:21:06,200
I cover how exactly can do that.
So when you talk about being 

369
00:21:06,200 --> 00:21:09,500
pragmatic, right, A lot of 
people has a certain number of 

370
00:21:09,500 --> 00:21:11,600
coverage that they would aim for
some. 

371
00:21:11,600 --> 00:21:13,400
Put it pretty high somebody in 
the middle. 

372
00:21:13,700 --> 00:21:16,600
What do you think is a good 
prank mattock number for code 

373
00:21:16,600 --> 00:21:19,400
coverage? 
And then when you say about 

374
00:21:19,400 --> 00:21:21,000
minimum maintenance, cause, 
right? 

375
00:21:21,000 --> 00:21:23,600
Can you explain a little bit, 
why some unit tests could 

376
00:21:23,600 --> 00:21:26,000
actually create a high 
maintenance cost? 

377
00:21:26,800 --> 00:21:30,500
Yeah, that's a good question. 
So, in terms of the specific 

378
00:21:30,500 --> 00:21:32,200
Commerce number, I wouldn't say 
intent. 

379
00:21:32,200 --> 00:21:37,000
There is any specific number and
that is good for any project. 

380
00:21:37,100 --> 00:21:40,700
I wouldn't even put specific 
coverage number as a target for 

381
00:21:40,700 --> 00:21:44,700
developers because you often can
see if that there is some 

382
00:21:44,700 --> 00:21:47,600
coverage number. 
Let's say 80% or 70%. 

383
00:21:47,800 --> 00:21:50,900
Ain't that is put as a Target 
and your built fails. 

384
00:21:50,900 --> 00:21:55,000
If you don't achieve that Target
or keep this, number goes below 

385
00:21:55,000 --> 00:21:58,100
that limit. 
This is not a very good practice

386
00:21:58,300 --> 00:22:03,000
because it introduces perverse 
incentives for your developers. 

387
00:22:03,300 --> 00:22:07,900
So you may end up in a situation
where the you write a lot of all

388
00:22:07,900 --> 00:22:12,200
over your past said that 
exercise basically useless cold 

389
00:22:12,300 --> 00:22:15,500
or cold. 
That is not very prone to bugs 

390
00:22:15,800 --> 00:22:20,100
or even as I mentioned earlier. 
Can just omit some assertions 

391
00:22:20,100 --> 00:22:23,200
because they are hard to 
implement and you just exercise 

392
00:22:23,200 --> 00:22:25,800
your code for the sake of 
increasing, these coverage 

393
00:22:25,800 --> 00:22:27,900
number. 
So first of all, you shouldn't 

394
00:22:27,900 --> 00:22:31,200
fail your bill because of some 
specific covers numbered at 

395
00:22:31,200 --> 00:22:34,900
most, that should be an alert 
that alerts your developers, 

396
00:22:34,900 --> 00:22:36,500
which prompts them to 
investigate. 

397
00:22:36,500 --> 00:22:40,100
Why the converse number has 
become so low, but the rule of 

398
00:22:40,100 --> 00:22:43,700
thumb here would be if you can, 
you should separate your domain 

399
00:22:43,700 --> 00:22:45,900
model from all other parts of 
your project. 

400
00:22:45,900 --> 00:22:49,900
The main model should Should 
have a high coverage number. 

401
00:22:49,900 --> 00:22:53,800
So this is the only part of your
project where you can possibly 

402
00:22:53,800 --> 00:22:55,600
Target some High coverage 
number. 

403
00:22:55,800 --> 00:22:59,300
Something like 90%, that would 
be justified in the vast 

404
00:22:59,300 --> 00:23:02,900
majority of cases, but you 
shouldn't apply these magic 

405
00:23:02,900 --> 00:23:06,700
blankly in your whole project. 
That would be counterproductive.

406
00:23:07,300 --> 00:23:09,000
The second question is about 
maintenance. 

407
00:23:09,200 --> 00:23:11,600
What do you think? 
Like way are the place where 

408
00:23:11,600 --> 00:23:14,200
sometimes in unit tests? 
You might have a high 

409
00:23:14,200 --> 00:23:17,700
maintenance cause right there. 
Elapsed several? 

410
00:23:18,100 --> 00:23:23,000
But the most prominent the most 
notorious area for tests, being 

411
00:23:23,000 --> 00:23:25,900
low value is when they are 
brittle. 

412
00:23:26,100 --> 00:23:30,700
So, when people write tests that
fail with, no good reason after 

413
00:23:30,700 --> 00:23:33,700
basically each refactoring and 
we can talk about this more 

414
00:23:33,700 --> 00:23:37,200
because this is one of the 
pillars of unit testing that I 

415
00:23:37,200 --> 00:23:39,800
also described in the books, one
of the four pillars. 

416
00:23:40,500 --> 00:23:43,900
So maybe let's move on to that 
four pillars to to describe the 

417
00:23:43,900 --> 00:23:46,200
different pillars that you have 
for a good unit test. 

418
00:23:46,900 --> 00:23:50,300
So the frame I work with that. 
I tried to lay out and it's 

419
00:23:50,300 --> 00:23:54,000
about four properties of a good 
unit test four pillars as I 

420
00:23:54,000 --> 00:23:57,800
called it in the book. 
They are first it is protection 

421
00:23:57,800 --> 00:24:01,100
against bugs. 
The second one is resilience to 

422
00:24:01,100 --> 00:24:04,300
refactoring. 
The third one is fast feedback 

423
00:24:04,300 --> 00:24:06,400
and the fourth one is 
maintainability. 

424
00:24:06,600 --> 00:24:10,300
So let's start with the second 
two and then we'll go back to 

425
00:24:10,300 --> 00:24:13,700
the first two because the second
two are easy to explain fast. 

426
00:24:13,700 --> 00:24:17,100
Feedback is pretty 
self-explanatory and it's about 

427
00:24:17,100 --> 00:24:21,100
how Your test, execute this 
metric is important because the 

428
00:24:21,100 --> 00:24:23,000
faster, your tests execute the 
quicker. 

429
00:24:23,000 --> 00:24:27,300
You get the feedback if your 
code stops working properly. 

430
00:24:27,500 --> 00:24:30,500
This saves you time. 
Moving in the wrong direction. 

431
00:24:30,800 --> 00:24:32,800
You need to. 
Just keep in mind that a block 

432
00:24:32,800 --> 00:24:36,200
found during development is 
basically Costless to fix. 

433
00:24:36,400 --> 00:24:40,600
It doesn't take you anything to 
fix this part but a bark that is

434
00:24:40,600 --> 00:24:43,300
found in later stages of 
development. 

435
00:24:43,300 --> 00:24:46,400
Let's say create or even in 
production, it requires orders 

436
00:24:46,400 --> 00:24:49,500
of magnitude more. 
Effort to fix the bug found in 

437
00:24:49,500 --> 00:24:54,800
development and so you want to 
push those box as far back to 

438
00:24:54,800 --> 00:24:56,600
the development stage as 
possible. 

439
00:24:56,900 --> 00:24:59,400
Fast unit tests, help you do 
exactly that. 

440
00:25:00,000 --> 00:25:03,700
The fourth metric is 
maintainability and it's a 

441
00:25:03,700 --> 00:25:07,500
function of how easy it is to 
read your tests and understand 

442
00:25:07,500 --> 00:25:10,100
them which itself is a function 
of whiskey. 

443
00:25:10,100 --> 00:25:13,800
How large your test is because 
larger you test the hardest on 

444
00:25:13,800 --> 00:25:18,100
the stand that past also they 
maintainability metric the And 

445
00:25:18,100 --> 00:25:22,800
subcategory that metric is how 
easy it is to maintain 

446
00:25:22,800 --> 00:25:25,200
dependencies with that test 
operational. 

447
00:25:25,400 --> 00:25:28,900
If your test works with out of 
France, dependency is such as 

448
00:25:28,900 --> 00:25:32,400
the data police, or the file 
system, or any other third party

449
00:25:32,400 --> 00:25:36,400
systems, you will have to 
maintain those dependencies for 

450
00:25:36,400 --> 00:25:38,000
that test. 
You will be ski. 

451
00:25:38,000 --> 00:25:40,800
Have to make sure that your 
database who science in the 

452
00:25:40,800 --> 00:25:44,700
proper state that your network 
connectivity is fine and so on 

453
00:25:44,700 --> 00:25:47,600
and so forth that also adds up 
maintainability. 

454
00:25:47,700 --> 00:25:51,100
Costs for your tests. 
So that was the third and the 

455
00:25:51,100 --> 00:25:54,800
fourth metrics. 
The first and trick is as sad is

456
00:25:54,800 --> 00:25:58,300
protection against box or 
protection against regressions. 

457
00:25:58,500 --> 00:26:03,200
It is How likely your test to 
catch the bug if you introduce 

458
00:26:03,200 --> 00:26:07,200
that bug in your code base, so 
that's basically a function of 

459
00:26:07,200 --> 00:26:11,700
how much of your coat your test 
executes, the larger that slice 

460
00:26:11,700 --> 00:26:14,900
of CO2 detector test executes, 
it the higher the probability 

461
00:26:14,900 --> 00:26:17,600
that your test will find the bug
and that code base. 

462
00:26:17,700 --> 00:26:21,500
That slice of cold, of course, 
given that your test has all the

463
00:26:21,500 --> 00:26:26,200
required assertions and then the
most controversial, or the 

464
00:26:26,200 --> 00:26:29,400
least, and would say, and the 
stood property of a good unit 

465
00:26:29,400 --> 00:26:33,000
test is resilience to 
refactoring and that is How 

466
00:26:33,000 --> 00:26:36,200
likely your test to fail to turn
red. 

467
00:26:36,200 --> 00:26:40,300
If you refactor the code that 
this test covers. 

468
00:26:40,300 --> 00:26:45,200
So another way to describe what 
this metric is, How likely your 

469
00:26:45,200 --> 00:26:49,300
tests to raise false. 
Arms or false positives. 

470
00:26:49,500 --> 00:26:52,800
And the false alarm is a 
situation where your test fails,

471
00:26:52,800 --> 00:26:54,900
but the underlying code works 
fine. 

472
00:26:55,100 --> 00:26:58,500
This usually happens when you 
refactor your code because when 

473
00:26:58,500 --> 00:27:01,600
you refractor, you change some 
implementation details of your 

474
00:27:01,600 --> 00:27:04,700
code base. 
And if your tests couple to 

475
00:27:04,700 --> 00:27:07,800
those implementation details, 
well, they may basically not 

476
00:27:07,800 --> 00:27:10,200
like that. 
You changed those details, and 

477
00:27:10,200 --> 00:27:13,600
they will notify you about those
details changed. 

478
00:27:13,700 --> 00:27:16,800
So, that's not how you want your
tests to work. 

479
00:27:16,900 --> 00:27:20,200
You want them? 
To whale only when you change 

480
00:27:20,200 --> 00:27:23,300
the observable behavior of your 
code, but it's not the 

481
00:27:23,300 --> 00:27:26,600
implementation details of it. 
And so, this second metric is, 

482
00:27:26,600 --> 00:27:30,800
what is responsible for test 
brittleness or test for Geology,

483
00:27:31,100 --> 00:27:34,600
the better this metric. 
The last French, all your tests 

484
00:27:34,600 --> 00:27:39,700
are and there are several things
that contribute to this metric. 

485
00:27:40,000 --> 00:27:43,600
In my experience this metric 
resilience to reflect on the 

486
00:27:43,600 --> 00:27:46,900
most important metric and it's 
at a single most important 

487
00:27:46,900 --> 00:27:49,500
factor. 
That differentiates between good

488
00:27:49,500 --> 00:27:53,900
and bad pasts because nowadays a
lot of developers understand the

489
00:27:53,900 --> 00:27:57,500
importance of the first mantric 
protection against regressions, 

490
00:27:57,800 --> 00:28:01,700
the third metric of tests being 
fast and the fourth metric, the 

491
00:28:01,700 --> 00:28:05,200
tasks being a lamentable, but 
not a lot of developers 

492
00:28:05,200 --> 00:28:08,100
understand the importance of the
second metric which is 

493
00:28:08,100 --> 00:28:11,700
resilience to refactoring. 
I can only speculate why that is

494
00:28:11,700 --> 00:28:16,700
but my idea is that you don't 
need refactoring right away. 

495
00:28:17,000 --> 00:28:20,100
So if we Outline. 
The importance of the first 

496
00:28:20,100 --> 00:28:23,100
metric protection against the 
regressions, and the second 

497
00:28:23,100 --> 00:28:27,700
metric with time, you will have 
these situation word protection 

498
00:28:27,700 --> 00:28:30,100
against blocks is important. 
Pretty much from the very 

499
00:28:30,100 --> 00:28:33,200
beginning of your project 
because you want your tests to 

500
00:28:33,200 --> 00:28:37,400
catch any bugs from the get-go, 
but with resilience to 

501
00:28:37,400 --> 00:28:40,300
refactoring, it's not as 
important in the beginning 

502
00:28:40,300 --> 00:28:43,900
because think portent skin 
refactoring is not as immediate 

503
00:28:43,900 --> 00:28:46,800
either because in the beginning 
of the project, your code 

504
00:28:46,800 --> 00:28:49,200
doesn't Eat a lot of 
refactorings. 

505
00:28:49,400 --> 00:28:53,600
It's only a when you introduce 
more and more features when your

506
00:28:53,600 --> 00:28:56,900
project involves you need to do 
refactoring. 

507
00:28:56,900 --> 00:28:59,500
You need to start doing constant
or factoring off your existing 

508
00:28:59,500 --> 00:29:03,300
code base to make sure that it 
reflects your new domain 

509
00:29:03,300 --> 00:29:05,400
knowledge, your viewer 
apartments and so on. 

510
00:29:05,800 --> 00:29:08,400
And so because you don't need 
refraction, right? 

511
00:29:08,400 --> 00:29:12,100
The way the importance of the 
second metric of your past 

512
00:29:12,200 --> 00:29:15,400
resilience to that refactoring 
is also not immediate. 

513
00:29:15,600 --> 00:29:18,900
That's why I think a lot of 
Developers Don't be too much 

514
00:29:18,900 --> 00:29:22,700
attention to that metric, but it
does come important as important

515
00:29:22,700 --> 00:29:25,600
as the first metric. 
When their project evolves, when

516
00:29:25,600 --> 00:29:29,700
it matures often times what you 
can see, and a lot of projects 

517
00:29:29,700 --> 00:29:34,300
is that you write tests and you 
are quite happy with those 

518
00:29:34,300 --> 00:29:37,500
tests. 
But then, when you write quite a

519
00:29:37,500 --> 00:29:40,100
bit of cold, you have to reflect
or something, you have to 

520
00:29:40,100 --> 00:29:43,300
introduce feature, that doesn't 
quite fit, your existing, code 

521
00:29:43,300 --> 00:29:45,200
base, your existing 
architecture. 

522
00:29:45,200 --> 00:29:47,800
And you need to do some 
modifications to that 

523
00:29:47,800 --> 00:29:49,800
architecture to that existing 
code base. 

524
00:29:50,000 --> 00:29:55,000
And that oftentimes leads to 
modifications, not only to your 

525
00:29:55,000 --> 00:29:58,700
production code, please, but to 
your tests as well, because they

526
00:29:58,700 --> 00:30:02,200
were structured in a way, it 
didn't, they coupled to those 

527
00:30:02,200 --> 00:30:04,900
implementation details and when 
you're a factor, those 

528
00:30:04,900 --> 00:30:07,800
implementation details you 
basically have to refactor your 

529
00:30:07,800 --> 00:30:11,200
tests as well. 
DC is an example of a false 

530
00:30:11,200 --> 00:30:15,700
positive of a false alarm when 
your tests raise those alarms, 

531
00:30:15,800 --> 00:30:19,200
and they are fools because it's 
Necessarily true that after 

532
00:30:19,200 --> 00:30:22,100
effect from you introduced in 
ebooks, your code base, you 

533
00:30:22,100 --> 00:30:25,100
might have refactored, 
everything perfectly, and the 

534
00:30:25,108 --> 00:30:28,800
cool to still working, but your 
tests will still fail, even 

535
00:30:28,800 --> 00:30:33,100
though your coat, my still work.
And so, this is the second 

536
00:30:33,100 --> 00:30:36,200
metric. 
You can also think of the first 

537
00:30:36,200 --> 00:30:39,600
two Matrix protection against 
regressions, or protection 

538
00:30:39,600 --> 00:30:43,100
against bugs and resilience to 
refactoring, you can think of 

539
00:30:43,100 --> 00:30:45,600
them as of signal-to-noise 
ratio. 

540
00:30:45,800 --> 00:30:50,500
It's when you have well, 
Basically a signal and / notes, 

541
00:30:50,700 --> 00:30:54,600
a signal part is what your first
metric gives you. 

542
00:30:54,800 --> 00:30:58,800
It gives you the possibility of 
the probability of catching any 

543
00:30:58,800 --> 00:31:00,600
regression Senor. 
Could weights. 

544
00:31:00,900 --> 00:31:04,700
The noise part is what 
resilience tour, fact on allows 

545
00:31:04,700 --> 00:31:08,200
you to minimize. 
So once again signal is how good

546
00:31:08,200 --> 00:31:13,000
your tests are at Kitchen in 
your box and noise is about how 

547
00:31:13,000 --> 00:31:16,600
many false alarms of those tests
race while they can't shoot 

548
00:31:16,600 --> 00:31:18,700
those books. 
Both of these metrics are 

549
00:31:18,700 --> 00:31:21,000
important. 
Well signal is important because

550
00:31:21,000 --> 00:31:24,200
it's obviously important for 
your tests to be able to catch 

551
00:31:24,200 --> 00:31:26,200
blocks because otherwise in, 
they were just useless. 

552
00:31:26,600 --> 00:31:30,500
But noise is also important. 
Because even if your tests are 

553
00:31:30,500 --> 00:31:34,700
able to teach any bugs in your 
software, even then, if they 

554
00:31:34,700 --> 00:31:38,900
raised a lot of noise, a lot of 
false alarms, then you will not 

555
00:31:38,900 --> 00:31:43,000
be able to differentiate proper 
failures from false failures. 

556
00:31:43,200 --> 00:31:47,400
So you will lose all that signal
in the sea of noise. 

557
00:31:47,600 --> 00:31:50,500
And then your tests generate. 
And so it's important to 

558
00:31:50,500 --> 00:31:54,500
maximize both of these metrics 
protection against bugs and 

559
00:31:54,500 --> 00:31:56,600
resilience of your tests to 
refactoring. 

560
00:31:57,700 --> 00:32:00,100
Thanks for the in-depth 
explanation about these four 

561
00:32:00,100 --> 00:32:02,100
pillars of four Matrix of unit 
tests. 

562
00:32:02,200 --> 00:32:05,300
I get a sense that some people 
might still be confused about 

563
00:32:05,300 --> 00:32:07,900
the second metric, which is 
resilience to refactoring. 

564
00:32:08,100 --> 00:32:10,500
I would also assume that when 
you do refactoring, of course 

565
00:32:10,500 --> 00:32:12,800
your test will fail, right, of 
course, you will need to also 

566
00:32:12,800 --> 00:32:15,800
change your task code, but few 
things that I pick up from your 

567
00:32:15,800 --> 00:32:17,700
explanation. 
Just now is that there's a 

568
00:32:17,708 --> 00:32:20,700
situation where the test could 
fail, but the actual production 

569
00:32:20,700 --> 00:32:23,600
code, is actually looking fine, 
which is what you called, post 

570
00:32:23,600 --> 00:32:25,800
positive. 
And the other one is actually 

571
00:32:25,800 --> 00:32:27,600
ran. 
The tests realize Is too much on

572
00:32:27,600 --> 00:32:30,900
implementation details. 
Could you maybe briefly explain 

573
00:32:30,900 --> 00:32:32,800
about this for people who buy be
confused? 

574
00:32:33,000 --> 00:32:36,400
What do you mean by a task? 
That should not rely too much on

575
00:32:36,400 --> 00:32:41,500
implementation detail. 
So you want your tests to check 

576
00:32:41,500 --> 00:32:45,200
the behavior of your cold from 
the end users perspective. 

577
00:32:45,300 --> 00:32:49,700
For example, if you have a class
that well, let's say it, renders

578
00:32:49,700 --> 00:32:54,000
some message, and it returns an 
HTML representational that 

579
00:32:54,000 --> 00:32:56,900
message as a result. 
There are two ways to change. 

580
00:32:57,400 --> 00:33:02,500
That class first is to check the
resultant HTML message as a 

581
00:33:02,500 --> 00:33:05,200
whole. 
And second is to check how 

582
00:33:05,200 --> 00:33:08,300
exactly this class generates at 
that HTML message. 

583
00:33:08,600 --> 00:33:13,700
This is an example of a good 
test and Baptist in the sense of

584
00:33:13,900 --> 00:33:17,000
a brutal test. 
The second version of that past,

585
00:33:17,000 --> 00:33:19,500
which checks, the internal 
implementation details is 

586
00:33:19,500 --> 00:33:22,900
brittle, because it binds, it 
couples to those implementation 

587
00:33:22,900 --> 00:33:25,600
details. 
It basically insists on a 

588
00:33:25,600 --> 00:33:28,500
specific implementation. 
Ocean of that class if you 

589
00:33:28,500 --> 00:33:31,900
change and that implementation 
that past will fail. 

590
00:33:32,100 --> 00:33:35,300
There are countless number of 
equally applicable 

591
00:33:35,300 --> 00:33:37,400
implementations. 
Usually when you implement 

592
00:33:37,400 --> 00:33:41,200
classes, that's why it's a bad 
idea to couple to specific 

593
00:33:41,300 --> 00:33:44,300
implementation of your class 
when you unit tests that class, 

594
00:33:44,500 --> 00:33:48,000
basically, because it will raise
too many false alarms, and that 

595
00:33:48,000 --> 00:33:51,100
will inhibit your ability to 
find blocks in your software 

596
00:33:51,100 --> 00:33:54,500
because you will not be able to 
rely on that desk with that 

597
00:33:54,500 --> 00:33:58,300
raises too many false positives.
I'm If it answers your question,

598
00:33:58,300 --> 00:34:01,500
but maybe you can elaborate on 
that with further questions. 

599
00:34:01,800 --> 00:34:02,400
Yeah. 
Sure. 

600
00:34:02,500 --> 00:34:05,100
I get a sense that we'll cover 
this more when we talk about 

601
00:34:05,100 --> 00:34:08,199
mocking later on, but you 
mentioned a couple times already

602
00:34:08,199 --> 00:34:11,900
that some of the bad practice of
doing a unit test, when you have

603
00:34:11,900 --> 00:34:14,800
a test with the assertion and 
then in terms of lines of code a

604
00:34:14,800 --> 00:34:18,100
long test, could you probably 
describe a little bit more about

605
00:34:18,100 --> 00:34:22,400
the anatomy of a good unit test?
Yeah, that's the second chapter 

606
00:34:22,400 --> 00:34:26,199
were I tried to provide a 
refresher on how unit test is 

607
00:34:26,199 --> 00:34:29,300
structured. 
So the usual structure as a 

608
00:34:29,300 --> 00:34:32,600
ranch act and cert structure 
where you have three parts of 

609
00:34:32,600 --> 00:34:35,699
unit tests. 
The first one, arranges some 

610
00:34:35,699 --> 00:34:40,199
input, we use or test pictures 
the second part in bulks of the 

611
00:34:40,199 --> 00:34:45,100
coat under test and third part. 
Asserted that the result of that

612
00:34:45,100 --> 00:34:48,600
application is correct. 
And there are some basic 

613
00:34:48,600 --> 00:34:50,699
guidelines here of how you shoot
and shoot. 

614
00:34:50,900 --> 00:34:52,900
And Implement those unit test 
parts. 

615
00:34:53,300 --> 00:34:57,200
And the first idea is that you 
shouldn't use if statements 

616
00:34:57,200 --> 00:35:02,100
anywhere in your tests because 
your tests should be as dumb as 

617
00:35:02,100 --> 00:35:04,800
possible. 
They basically need to verify. 

618
00:35:04,800 --> 00:35:10,700
Only one use case with those if 
statements you diverge from that

619
00:35:10,700 --> 00:35:15,000
guideline, you start to check 
multiple use cases with just one

620
00:35:15,000 --> 00:35:17,300
test. 
This is bad because your unit 

621
00:35:17,300 --> 00:35:20,700
test is called as well, if you 
introduce. 

622
00:35:20,800 --> 00:35:24,600
Exit E2, that code, it becomes 
more prone to bugs. 

623
00:35:24,800 --> 00:35:27,900
That's something that you want 
to avoid because you don't have 

624
00:35:27,900 --> 00:35:31,700
other set of tests that test 
these tests you basically want 

625
00:35:31,700 --> 00:35:36,000
your task to be as simple as 
possible so that they don't have

626
00:35:36,000 --> 00:35:39,200
any box in themselves. 
So, that's the first guideline, 

627
00:35:39,600 --> 00:35:43,000
the second guideline. 
Well, I would say that this is 

628
00:35:43,000 --> 00:35:45,900
the most important guideline to 
the second. 

629
00:35:45,900 --> 00:35:49,500
Most important guideline is that
your test should be autonomous. 

630
00:35:49,700 --> 00:35:51,900
They shouldn't depend. 
And on each other. 

631
00:35:52,100 --> 00:35:56,300
So what you often see is that 
when you have a class that 

632
00:35:56,300 --> 00:36:00,800
contains several tests, you may 
introduce some duplications in 

633
00:36:00,800 --> 00:36:03,600
those tests. 
The first inclination of lot of 

634
00:36:03,600 --> 00:36:07,600
developers is to extract those 
duplications into something 

635
00:36:07,600 --> 00:36:11,500
like, class feels or class 
properties, which, you can reuse

636
00:36:11,500 --> 00:36:14,500
in those test. 
This is understandable, and it 

637
00:36:14,500 --> 00:36:17,800
is good for production code, but
it is not a good practice for 

638
00:36:17,800 --> 00:36:20,900
your test code. 
Because another important Line 

639
00:36:20,900 --> 00:36:23,200
here. 
Important property of a good 

640
00:36:23,200 --> 00:36:26,300
test is that they do not depend 
on each other. 

641
00:36:26,500 --> 00:36:30,000
This is important because you 
don't want your tests to fail. 

642
00:36:30,000 --> 00:36:32,100
When you modify some other 
tests. 

643
00:36:32,300 --> 00:36:35,400
You want them to be independent 
from each other and you want 

644
00:36:35,400 --> 00:36:38,700
them to test their own aspects 
of the production code base 

645
00:36:38,700 --> 00:36:42,500
independently from each other. 
So I would say, then these two 

646
00:36:42,500 --> 00:36:46,400
are the most important 
guidelines when it comes to just

647
00:36:46,400 --> 00:36:49,000
some foundational guidelines or 
basic guidelines. 

648
00:36:49,800 --> 00:36:52,700
And I guess the other one is 
about assertions itself, right 

649
00:36:52,700 --> 00:36:55,800
invention like test without 
assertion, or how about multiple

650
00:36:55,800 --> 00:36:57,400
assertions? 
Yeah. 

651
00:36:57,400 --> 00:37:00,700
This is a debatable topic. 
There is an opinion. 

652
00:37:00,700 --> 00:37:03,500
That there is a view of that 
unit tests should contain only 

653
00:37:03,500 --> 00:37:06,100
one assertion. 
I disagree, with that opinion. 

654
00:37:06,100 --> 00:37:10,400
And I think that a test can 
contain multiple assertions. 

655
00:37:10,400 --> 00:37:13,600
That's perfectly fine. 
This view on a test. 

656
00:37:13,600 --> 00:37:17,400
Having only one assertion comes 
from another presupposition. 

657
00:37:17,400 --> 00:37:20,700
I would say. 
So this is The View that unit 

658
00:37:20,700 --> 00:37:23,700
test should only cover a small 
piece of code. 

659
00:37:23,900 --> 00:37:27,100
This is also incorrect in my 
opinion because it's not the 

660
00:37:27,100 --> 00:37:30,500
code, that is important for test
coverage. 

661
00:37:30,500 --> 00:37:34,000
It is a specific unit of 
behavior that your unit tests 

662
00:37:34,000 --> 00:37:37,100
should cover the size of the 
code that it takes you to 

663
00:37:37,100 --> 00:37:39,000
implement that behavior is 
relevant. 

664
00:37:39,000 --> 00:37:41,900
Here. 
It may take you one class, one 

665
00:37:41,900 --> 00:37:45,200
method or multiple classes. 
Is a sighted shouldn't matter 

666
00:37:45,200 --> 00:37:48,500
for your unit test. 
Even if your unit of behavior 

667
00:37:48,500 --> 00:37:51,900
takes multiple. 
Classes, you should test that 

668
00:37:51,900 --> 00:37:56,200
unit of behavior as one unit. 
So you should create all these 

669
00:37:56,300 --> 00:37:59,900
multiple classes than invoked 
are here under under test. 

670
00:37:59,900 --> 00:38:04,100
And then you can ascertain, the 
result of that vacation, using 

671
00:38:04,100 --> 00:38:07,500
those multiple classes. 
So you can assert part of the 

672
00:38:07,500 --> 00:38:10,600
result in one class part of the 
result in the second class. 

673
00:38:10,800 --> 00:38:14,800
And so that's why I believe that
multiple assertions protest, he 

674
00:38:14,800 --> 00:38:18,400
is perfectly fine. 
So I think this is a good segue 

675
00:38:18,400 --> 00:38:21,200
to move to the mocking. 
Sometimes you would do this 

676
00:38:21,200 --> 00:38:24,300
mocking techniques or maybe some
other test doubles that people 

677
00:38:24,300 --> 00:38:27,100
need to do in order to structure
the particular class of the 

678
00:38:27,100 --> 00:38:30,500
particular method in order to 
have the proper arrange, the 

679
00:38:30,500 --> 00:38:32,700
first step of the arranged I can
assert. 

680
00:38:32,900 --> 00:38:35,700
So could you maybe share a so 
that the bit more about this 

681
00:38:35,700 --> 00:38:39,500
technique about test doubles 
about mocking and yeah probably 

682
00:38:39,500 --> 00:38:43,000
will suffer from that. 
This is another controversial, a

683
00:38:43,000 --> 00:38:46,200
pretty controversial topic of 
where exactly, you should apply 

684
00:38:46,200 --> 00:38:48,600
more. 
There are two schools of thought

685
00:38:48,600 --> 00:38:51,300
he had two major schools of 
thought. 

686
00:38:51,300 --> 00:38:53,600
The first one is the London 
school. 

687
00:38:53,800 --> 00:38:59,100
It is also sometimes called Mark
East school and it advocates for

688
00:38:59,100 --> 00:39:02,300
applying marks for any 
dependencies other than 

689
00:39:02,300 --> 00:39:04,600
immutable dependencies and other
school. 

690
00:39:04,600 --> 00:39:07,900
He is at the classical school or
classic school and this school 

691
00:39:07,900 --> 00:39:11,500
is also called Detroit or 
Chicago School of unit, testing.

692
00:39:11,600 --> 00:39:15,900
This cool air is about applying 
marking only for out of 

693
00:39:15,900 --> 00:39:17,800
practice. 
Dependencies such as the 

694
00:39:17,800 --> 00:39:22,700
database SMTP service. 
And so, on Marx is one of the 

695
00:39:22,700 --> 00:39:26,800
most frequent reasons for your 
tests being brittle. 

696
00:39:26,800 --> 00:39:30,700
So they affect the second 
property of a good unit tests. 

697
00:39:30,700 --> 00:39:32,500
A lot. 
The second property being 

698
00:39:32,500 --> 00:39:36,100
resilience to refactoring, 
that's because marks are good 

699
00:39:36,100 --> 00:39:38,400
way to cement. 
The way. 

700
00:39:38,400 --> 00:39:42,700
The system under test works with
its dependencies usually don't 

701
00:39:42,700 --> 00:39:46,200
want these communication pattern
between the system under test 

702
00:39:46,200 --> 00:39:49,200
and Dependencies don't want it 
to be cemented. 

703
00:39:49,200 --> 00:39:52,300
You don't want it to be set in 
stone because it, that is an 

704
00:39:52,300 --> 00:39:55,300
implementation detail. 
As I said, the London school and

705
00:39:55,300 --> 00:39:59,700
her kids for using marks for any
mutable dependencies, to provide

706
00:39:59,700 --> 00:40:01,500
an example. 
Let's say that you could test 

707
00:40:01,500 --> 00:40:05,600
the user class and this class 
has another Clause company as a 

708
00:40:05,600 --> 00:40:08,700
dependency and that company 
class is mutable. 

709
00:40:08,800 --> 00:40:12,500
Then these company class would 
be a dependency for the system 

710
00:40:12,500 --> 00:40:15,400
under test and this dependency 
would be mutable. 

711
00:40:15,600 --> 00:40:19,000
And so with a lot, And on school
would advocate for mocking this 

712
00:40:19,000 --> 00:40:21,700
dependency in tests. 
So, basically, for replacing 

713
00:40:21,700 --> 00:40:24,700
that dependency with detestable,
this is a better approach 

714
00:40:24,700 --> 00:40:27,700
because it has sapped the 
particular way of communication 

715
00:40:27,700 --> 00:40:31,600
between the user and the company
has nothing to do with the user 

716
00:40:31,600 --> 00:40:34,900
of that duration that has 
nothing to do with how the end 

717
00:40:34,900 --> 00:40:37,600
user perceives the result of 
that operation. 

718
00:40:37,800 --> 00:40:42,400
So what matters is the aunt 
state of these two classes of 

719
00:40:42,400 --> 00:40:45,500
the user class and the company 
class how exactly they 

720
00:40:45,500 --> 00:40:48,700
communicated with Each other to 
achieve that end state is not 

721
00:40:48,700 --> 00:40:51,000
important at all. 
The company classy. 

722
00:40:51,000 --> 00:40:53,700
Shouldn't bind your tests to 
these specific way. 

723
00:40:53,700 --> 00:40:55,800
These two classes communicate 
with each other. 

724
00:40:56,000 --> 00:40:58,300
Otherwise, it would lead to task
brittleness. 

725
00:40:58,600 --> 00:41:03,300
So that's why I think the London
school is incorrect about the 

726
00:41:03,300 --> 00:41:06,500
use of mocks. 
The classical school is a sad. 

727
00:41:06,600 --> 00:41:10,300
It doesn't advocate for the use 
of marks for all mutable 

728
00:41:10,300 --> 00:41:13,200
dependencies. 
But only for those of them that 

729
00:41:13,200 --> 00:41:16,400
are out of process. 
For example, the database, the A

730
00:41:16,408 --> 00:41:20,700
classical school, I would say 
that it also is incorrect in its

731
00:41:20,700 --> 00:41:23,800
treatment of marks. 
That's because just like, you 

732
00:41:23,800 --> 00:41:26,800
shouldn't mock in-process 
mutable dependencies. 

733
00:41:26,900 --> 00:41:29,500
You also shouldn't mock all out 
of process. 

734
00:41:29,500 --> 00:41:32,600
Mutable dependencies to describe
this point. 

735
00:41:32,600 --> 00:41:36,700
We need to take a step back and 
talk about how applications 

736
00:41:36,700 --> 00:41:40,200
evolve together. 
And what is the main benefit of 

737
00:41:40,200 --> 00:41:43,600
mocks the main benefit of my ex 
when it comes to unit testing. 

738
00:41:43,600 --> 00:41:47,600
Is that, as I said, it allows 
you to semantics Way, your 

739
00:41:47,600 --> 00:41:51,300
system under test communicates, 
with those dependencies, you 

740
00:41:51,300 --> 00:41:55,300
only want to do that. 
If that communication is part of

741
00:41:55,300 --> 00:41:57,300
observable behavior of your 
software. 

742
00:41:57,700 --> 00:41:59,700
It is part of observable 
behavior. 

743
00:41:59,700 --> 00:42:03,000
Only, when the communication 
with that dependency, is visible

744
00:42:03,000 --> 00:42:05,800
to the outside world, for 
example, to the client who 

745
00:42:05,800 --> 00:42:08,400
invoked some alteration in your 
system. 

746
00:42:08,800 --> 00:42:11,500
So, let's take some example. 
Now, let's see that. 

747
00:42:11,500 --> 00:42:14,300
You develop an API and 
disappear. 

748
00:42:14,300 --> 00:42:16,300
I works with two out of 
practice. 

749
00:42:16,400 --> 00:42:18,800
Dependencies. 
The first one is application 

750
00:42:18,800 --> 00:42:21,700
database and the second one is a
master bus. 

751
00:42:22,000 --> 00:42:26,100
So the client application 
invokes, your API and the result

752
00:42:26,100 --> 00:42:30,000
of that implication would be 
that your application modifies, 

753
00:42:30,000 --> 00:42:34,000
some state in the database. 
And it also amides a message on 

754
00:42:34,000 --> 00:42:37,000
the message bus. 
The question here is, which of 

755
00:42:37,000 --> 00:42:38,800
these two out of practice 
dependencies. 

756
00:42:38,800 --> 00:42:41,400
You should Mark the database and
the message bus. 

757
00:42:41,700 --> 00:42:45,100
You need to look at how your 
application involves together 

758
00:42:45,100 --> 00:42:48,000
with those out of practice. 
Pendants, it's the main guide 

759
00:42:48,000 --> 00:42:51,200
line here is that you should 
enable backwards compatibility 

760
00:42:51,200 --> 00:42:54,300
of when you deploy new versions 
of your software and that's 

761
00:42:54,300 --> 00:42:58,500
because you cannot deploy your 
application smelt Aeneas lie 

762
00:42:58,500 --> 00:43:01,500
with other applications that 
depend on your software. 

763
00:43:01,700 --> 00:43:04,300
For example, when you develop 
microservice in your 

764
00:43:04,300 --> 00:43:08,200
organization, and then there is 
another micro service event, 

765
00:43:08,200 --> 00:43:12,800
depends on your application, or 
that reads the messages that you

766
00:43:12,800 --> 00:43:17,500
put on the bus, if those micro 
servicers are Lloyd separately, 

767
00:43:17,500 --> 00:43:21,100
for example, your microservices 
is developed by your team and 

768
00:43:21,200 --> 00:43:24,000
this second microservices 
deployed by a separate team in 

769
00:43:24,000 --> 00:43:26,800
the same organization. 
You may not be able to deploy 

770
00:43:26,800 --> 00:43:29,600
them simultaneously. 
And so when you introduce you 

771
00:43:29,600 --> 00:43:32,500
versions, you should maintain 
backward compatibility so that 

772
00:43:32,500 --> 00:43:35,500
the clients of your software 
will be able to catch up 

773
00:43:35,500 --> 00:43:39,000
benchley and start to use new 
versions of your interface. 

774
00:43:39,000 --> 00:43:41,500
But before that, you should 
still be able to use it, the old

775
00:43:41,500 --> 00:43:45,400
version of that interface to 
help you with maintaining that 

776
00:43:45,400 --> 00:43:49,100
backward compatibility. 
This is where Marx come helpful 

777
00:43:49,300 --> 00:43:51,400
because of this is their primary
goal. 

778
00:43:51,400 --> 00:43:53,800
They allow you to make sure that
the communication pattern 

779
00:43:53,800 --> 00:43:57,200
between your application and the
message bus remains of the same.

780
00:43:57,500 --> 00:43:59,900
As I said, you cannot change 
these communication pattern, 

781
00:43:59,900 --> 00:44:02,500
because if you change the 
structure of your messages, that

782
00:44:02,500 --> 00:44:05,700
your application, amit's on the 
bus, then they add applications 

783
00:44:05,700 --> 00:44:07,400
will not understand those 
messages. 

784
00:44:07,500 --> 00:44:09,500
You have to maintain these data 
contract. 

785
00:44:09,500 --> 00:44:12,800
Between those two applications. 
This is where Marx will be 

786
00:44:12,800 --> 00:44:15,400
helpful. 
They will help you to samaan to 

787
00:44:15,400 --> 00:44:19,100
these A pattern between your 
application and this message 

788
00:44:19,100 --> 00:44:23,000
bus, but at the same time, these
backward compatibility is not 

789
00:44:23,000 --> 00:44:25,300
the case for the application 
database. 

790
00:44:25,400 --> 00:44:29,000
And that's because no other 
application has a direct access 

791
00:44:29,000 --> 00:44:32,900
to that database. 
You are able to deploy your code

792
00:44:32,900 --> 00:44:35,900
base, your project alongside 
with database. 

793
00:44:35,900 --> 00:44:39,100
So you're basically deploy the 
database with your project 

794
00:44:39,100 --> 00:44:41,200
simultaneously. 
And so there is no backward. 

795
00:44:41,200 --> 00:44:44,100
Compatibility requirement 
between your application and the

796
00:44:44,100 --> 00:44:45,900
database. 
That's why you shouldn't use 

797
00:44:45,900 --> 00:44:48,300
mocks. 
When you check your database 

798
00:44:48,300 --> 00:44:50,900
because those Communications 
between your application and the

799
00:44:50,900 --> 00:44:53,900
database, they are also 
implementation details because 

800
00:44:53,900 --> 00:44:57,600
if they are not visible to the 
outside world, this prayer of 

801
00:44:57,600 --> 00:44:59,900
two applications, your 
application and the database, 

802
00:45:00,100 --> 00:45:04,500
they essentially act as one 
system and the dual-sim. 

803
00:45:04,500 --> 00:45:08,600
So from the end user perspective
because of the end user doesn't 

804
00:45:08,600 --> 00:45:11,000
know that you have a database 
behind the scenes. 

805
00:45:11,200 --> 00:45:14,100
The only thing it knows is that 
you provide some of the eyes for

806
00:45:14,100 --> 00:45:18,100
that and user and then when it 
involves So those apis the state

807
00:45:18,100 --> 00:45:21,700
some of your data changes, but 
it doesn't see the data itself. 

808
00:45:21,800 --> 00:45:25,000
It can only reach out to the 
Theta through your IP eyes. 

809
00:45:25,300 --> 00:45:28,800
And so because in this 
situation, your system behaves 

810
00:45:28,800 --> 00:45:32,700
as one with the database, you 
shouldn't mock the 

811
00:45:32,700 --> 00:45:35,500
communications between your 
application and this database, 

812
00:45:35,600 --> 00:45:39,100
you only need to check the end 
result of those Communications. 

813
00:45:39,100 --> 00:45:42,600
So the state of your database 
after that parisians completed, 

814
00:45:42,700 --> 00:45:45,700
but again, it's not the keys for
the message bus because 

815
00:45:45,700 --> 00:45:48,700
communication, Sweet. 
The message parts are visible to

816
00:45:48,700 --> 00:45:51,300
the outside world. 
They are visible to the client 

817
00:45:51,300 --> 00:45:54,200
or other applications who work 
with your application. 

818
00:45:54,500 --> 00:45:58,400
And so here, if we go back to 
the mocking topic from the 

819
00:45:58,400 --> 00:46:01,600
classical perspective, all out 
of process dependencies can be 

820
00:46:01,600 --> 00:46:05,800
subdivided into two categories. 
The first one is managed 

821
00:46:05,800 --> 00:46:09,500
dependencies, and the second one
is unmanaged dependencies. 

822
00:46:09,800 --> 00:46:12,400
When it's dependencies, is 
basically an application 

823
00:46:12,400 --> 00:46:14,800
database. 
It is the communications with 

824
00:46:14,800 --> 00:46:18,200
which are not visible to the The
outside world and you shouldn't 

825
00:46:18,200 --> 00:46:21,600
mock those dependencies. 
You should only mark on mens 

826
00:46:21,600 --> 00:46:24,100
dependencies. 
This is something like a message

827
00:46:24,100 --> 00:46:27,000
bars and third-party your 
system, something like a 

828
00:46:27,000 --> 00:46:30,700
payment, the pi at third part 2 
micro service or something like 

829
00:46:30,700 --> 00:46:34,500
an SMTP service. 
So this is something that you do

830
00:46:34,500 --> 00:46:37,200
need to mark because 
Communications with those 

831
00:46:37,200 --> 00:46:40,600
dependencies are visible. 
Externally, they are observable 

832
00:46:40,600 --> 00:46:43,800
externally and so you shoot 
maintain backward, compatibility

833
00:46:43,800 --> 00:46:47,000
with those dependencies. 
Thank you for The in-depth 

834
00:46:47,000 --> 00:46:48,900
explanation, including some 
examples. 

835
00:46:48,900 --> 00:46:51,500
You mentioned a lot of things 
here, especially including like 

836
00:46:51,500 --> 00:46:52,900
some styles of unit. 
Testing. 

837
00:46:52,900 --> 00:46:56,200
Be it like asserting just the 
end result of the output and 

838
00:46:56,200 --> 00:46:59,400
also like how do you also check 
whether the state after certain 

839
00:46:59,400 --> 00:47:01,700
operation runs? 
Whether it's correct. 

840
00:47:01,700 --> 00:47:04,500
Also communication right bike, 
for example, third-party message

841
00:47:04,500 --> 00:47:06,700
bars and database. 
So thanks for explaining all 

842
00:47:06,700 --> 00:47:10,100
this in one go. 
So before we move on to the last

843
00:47:10,100 --> 00:47:12,700
section of the composition, 
which is about three, tactics 

844
00:47:12,700 --> 00:47:15,700
them before that. 
Maybe if you can give us some 

845
00:47:15,700 --> 00:47:18,000
and deeper. 
Turns or bad practices of unit 

846
00:47:18,000 --> 00:47:21,100
tests for people to know be 
aware of, that's the first 

847
00:47:21,100 --> 00:47:23,200
thing. 
And also for them not to repeat 

848
00:47:23,200 --> 00:47:25,000
the same mistakes. 
Yeah. 

849
00:47:25,000 --> 00:47:28,300
There are some common, 
widespread anti-patterns amount 

850
00:47:28,300 --> 00:47:32,100
comes to you testing. 
They all flow from these four 

851
00:47:32,100 --> 00:47:35,900
pillars of a good unit tests. 
They all can be derived from 

852
00:47:35,900 --> 00:47:39,600
these four properties, but it's 
still interesting to reiterate 

853
00:47:39,600 --> 00:47:43,200
those patterns on their own. 
Well, just review them because 

854
00:47:43,200 --> 00:47:46,200
they are quite common as that. 
I would say theme more. 

855
00:47:46,400 --> 00:47:50,400
Common anti-pattern is unit, 
testing private methods and 

856
00:47:50,400 --> 00:47:52,600
unit. 
Testing private state of your 

857
00:47:52,600 --> 00:47:55,500
production code, please. 
This is bad because private 

858
00:47:55,500 --> 00:47:59,000
methods, they are private for a 
reason and that reason is 

859
00:47:59,000 --> 00:48:01,900
usually because your production 
could be is doesn't need them. 

860
00:48:02,100 --> 00:48:05,500
So, let's say, if we take a 
class and it has some public 

861
00:48:05,500 --> 00:48:09,000
mountains and also has some 
private methods, those methods 

862
00:48:09,000 --> 00:48:12,800
are private because declines of 
that class doesn't need to know 

863
00:48:12,800 --> 00:48:16,100
about those methods. 
So those methods are not part of

864
00:48:16,100 --> 00:48:19,200
the The public API of the 
observable behavior of that 

865
00:48:19,200 --> 00:48:22,500
Clause by exposing them. 
Just for the sake of unit, 

866
00:48:22,500 --> 00:48:26,100
testing you by definition, 
exposed implementation details. 

867
00:48:26,100 --> 00:48:29,200
Because of those private 
methods, they are by definition 

868
00:48:29,200 --> 00:48:32,900
implementation details and so by
finding your tests to those 

869
00:48:32,900 --> 00:48:36,400
implementation details, you'll 
make your tests fragile, make 

870
00:48:36,400 --> 00:48:40,600
them more brittle. 
This is also a consequence of 

871
00:48:40,700 --> 00:48:43,900
violating the second pillar of a
good unit test. 

872
00:48:44,100 --> 00:48:45,900
So its resilience to 
refactoring. 

873
00:48:46,300 --> 00:48:49,900
Swen, you blind your tests and 
coupled them to implementation 

874
00:48:49,900 --> 00:48:53,400
details instead of observable 
behavior of the production code.

875
00:48:53,700 --> 00:48:56,500
The second most common 
anti-pattern is similar. 

876
00:48:56,500 --> 00:49:01,300
It's about exposing not methods,
but state, it is also important 

877
00:49:01,300 --> 00:49:03,800
to avoid that. 
Basically for the same reasons, 

878
00:49:04,000 --> 00:49:08,000
because in your production code,
if some class has private State,

879
00:49:08,200 --> 00:49:12,100
this state is private also for 
reason is because the clients of

880
00:49:12,100 --> 00:49:14,500
that class. 
I don't need that state to 

881
00:49:14,500 --> 00:49:19,400
operate and so it Also becomes 
blind ation detail by definition

882
00:49:19,400 --> 00:49:22,500
because there are no client in 
the production code that require

883
00:49:22,500 --> 00:49:25,700
that state. 
So when you bind your tests to 

884
00:49:25,700 --> 00:49:30,300
that private State, you are also
violating the second pillar, you

885
00:49:30,300 --> 00:49:34,000
are making your tests less 
resilient to refactoring because

886
00:49:34,000 --> 00:49:36,600
when you change that 
implementation detail, it's a 

887
00:49:36,600 --> 00:49:39,200
you might defy it way, you store
that private State. 

888
00:49:39,200 --> 00:49:41,600
You will have to update your 
tests as well. 

889
00:49:41,800 --> 00:49:44,700
And you don't want to do that. 
You only want to update your 

890
00:49:44,700 --> 00:49:48,300
tests when they point out. 
Out modification in The Observer

891
00:49:48,300 --> 00:49:50,200
here, not implementation 
details. 

892
00:49:50,500 --> 00:49:53,800
So I would say these are the two
most prominent and their 

893
00:49:53,800 --> 00:49:55,500
patterns when it comes to unit 
testing. 

894
00:49:56,400 --> 00:49:58,900
So thank you so much Vladimir 
for all this knowledge about 

895
00:49:58,900 --> 00:50:02,200
unit testing best practices what
to avoid what to do. 

896
00:50:02,500 --> 00:50:04,800
So I really enjoyed that and I 
learned a lot myself. 

897
00:50:05,000 --> 00:50:07,100
But before I let you go, 
normally, I have this one 

898
00:50:07,100 --> 00:50:09,700
question for all my guests, 
which is for you to share your 

899
00:50:09,700 --> 00:50:11,700
tree. 
Technical leadership is them so 

900
00:50:11,700 --> 00:50:15,800
that people can learn from you. 
I'm sure I can come up with 3x 

901
00:50:15,900 --> 00:50:20,200
and what I have one, so, I would
say, put your thoughts in 

902
00:50:20,200 --> 00:50:22,100
writing. 
This comes from my personal 

903
00:50:22,100 --> 00:50:23,900
experience. 
Because as I said, when I 

904
00:50:23,900 --> 00:50:28,500
started blogging at my block, I 
forced myself to learn much more

905
00:50:28,500 --> 00:50:31,800
than I learned before, even 
though, before that I worked as 

906
00:50:31,800 --> 00:50:35,300
a programmer for almost 10 years
and still since I started 

907
00:50:35,300 --> 00:50:39,100
blogging I learned much more 
than 10 years prior to that. 

908
00:50:39,300 --> 00:50:43,500
This is the main reason why you 
should put your thoughts in 

909
00:50:43,500 --> 00:50:45,600
writing. 
Because they force you to 

910
00:50:45,600 --> 00:50:50,000
structure, your thoughts and 
even if no one reads that stuff.

911
00:50:50,200 --> 00:50:52,900
And by the way, I do recommend 
that you make those thoughts 

912
00:50:52,900 --> 00:50:56,000
public. 
Because even if nobody will read

913
00:50:56,100 --> 00:50:59,400
your thoughts, it still 
beneficial for yourself because 

914
00:50:59,400 --> 00:51:03,400
you will be forced to structure 
your thoughts and to find 

915
00:51:03,400 --> 00:51:05,500
connections that you didn't find
before. 

916
00:51:05,700 --> 00:51:09,200
Even if you somehow 
subconsciously, understood some 

917
00:51:09,200 --> 00:51:12,300
topics, some prominent topics. 
You probably didn't understand 

918
00:51:12,300 --> 00:51:16,600
them as deeply We as after you 
start to write about them. 

919
00:51:16,800 --> 00:51:21,500
So that's my main advice for 
everyone, just to clarify this. 

920
00:51:21,600 --> 00:51:24,500
When you say put thoughts in 
writing is not writing code, 

921
00:51:24,500 --> 00:51:27,000
right? 
Yeah, it's more about blogging. 

922
00:51:27,500 --> 00:51:30,700
So, thanks again for the me for 
people who want to connect with 

923
00:51:30,700 --> 00:51:33,900
you, or follow the discussion 
about unit testing further when 

924
00:51:33,900 --> 00:51:37,200
they can find you. 
Yeah, their main touch point in 

925
00:51:37,200 --> 00:51:40,200
his, my blog and Enterprise 
craftsmanship.com. 

926
00:51:40,400 --> 00:51:43,600
So I recommend my book, you need
testing free. 

927
00:51:43,800 --> 00:51:46,600
Police practices and patterns. 
And by the way, these books 

928
00:51:46,600 --> 00:51:49,800
together, the highest reading 
among all books, published by 

929
00:51:49,800 --> 00:51:52,100
Manning according to my tech 
editor. 

930
00:51:52,400 --> 00:51:54,500
So yeah, definitely recommend 
you. 

931
00:51:54,500 --> 00:51:57,400
Check out the book and also 
check out my courses on puerile 

932
00:51:57,400 --> 00:51:59,300
sites. 
They are about the main German 

933
00:51:59,300 --> 00:52:01,500
design and Mica my model secure 
Essence on. 

934
00:52:02,100 --> 00:52:05,400
So, for the technology Now 
podcast listener, I have a 

935
00:52:05,400 --> 00:52:07,600
special discount for all, 
meaning books. 

936
00:52:07,900 --> 00:52:11,100
And also, for this episode 
itself, will be giving you one 

937
00:52:11,100 --> 00:52:14,600
free ebook for giveaway. 
So make sure to To get that book

938
00:52:14,600 --> 00:52:17,700
so that you can learn about unit
testing and plus, let me set. 

939
00:52:17,700 --> 00:52:20,200
It's a highly rated book. 
So, thanks again Vladimir. 

940
00:52:20,400 --> 00:52:22,600
I really enjoyed this 
conversation and see you next 

941
00:52:22,600 --> 00:52:24,100
time. 
Thank you so much. 

942
00:52:24,100 --> 00:52:29,600
Thanks for having me. 
Thank you for listening to this 

943
00:52:29,600 --> 00:52:32,200
episode and for staying right 
till the end. 

944
00:52:32,400 --> 00:52:35,300
If you highly enjoyed, please 
share it with your friends and 

945
00:52:35,300 --> 00:52:38,600
colleagues who you think would 
also benefit from listening to 

946
00:52:38,600 --> 00:52:40,900
this episode. 
And if you're new to the 

947
00:52:40,900 --> 00:52:44,200
podcast, make sure to subscribe 
and leave me your valuable 

948
00:52:44,200 --> 00:52:47,600
review and feedback. 
It really, really helps me a lot

949
00:52:47,600 --> 00:52:50,100
in order to grow these podcasts 
better. 

950
00:52:50,700 --> 00:52:54,000
You can also find the full show 
notes of this conversation on 

951
00:52:54,000 --> 00:52:55,900
the episode page at tackling 
journal. 

952
00:52:55,900 --> 00:52:59,000
The death website. 
Putting the full transcript 

953
00:52:59,000 --> 00:53:02,700
interesting quotes and links to 
the resources and mentions from 

954
00:53:02,700 --> 00:53:05,500
the conversation. 
And lastly make sure to 

955
00:53:05,500 --> 00:53:08,000
subscribe to the show's mailing 
list on technology. 

956
00:53:08,000 --> 00:53:11,500
No, the deaf to get notified for
any future episodes. 

957
00:53:11,800 --> 00:53:14,500
Stay tuned for the next 
technique Journal episode. 

958
00:53:14,600 --> 00:53:16,200
And until then. 
Goodbye.