1
00:00:00,040 --> 00:00:03,840
Welcome back to the Deep Dive. 
Today we're going to try and cut

2
00:00:03,840 --> 00:00:07,200
through some of the jargon 
around a really vital concept in

3
00:00:07,200 --> 00:00:09,360
software development unit 
testing. 

4
00:00:09,720 --> 00:00:12,000
Yeah, it's a term you hear 
thrown around a lot. 

5
00:00:12,000 --> 00:00:13,920
Exactly. 
You've probably heard it, but 

6
00:00:14,040 --> 00:00:16,280
what does it actually mean? 
Why is it so important? 

7
00:00:16,280 --> 00:00:19,080
And, you know, how do the big 
tech companies really use it 

8
00:00:19,080 --> 00:00:21,040
day-to-day? 
Good questions. 

9
00:00:21,280 --> 00:00:24,280
It's easy to see it as just like
a technical detail, right? 

10
00:00:25,080 --> 00:00:28,400
So our goal today is to give you
a shortcut to understanding it 

11
00:00:28,400 --> 00:00:30,880
better. 
We're leaning on software 

12
00:00:30,880 --> 00:00:35,200
Engineering, a Modern Approach 
by Marco Tulio Valente. 

13
00:00:35,200 --> 00:00:37,880
It's a great source for this. 
We'll start with the basics, the

14
00:00:37,880 --> 00:00:40,120
definitions, then we'll get into
the timing. 

15
00:00:40,120 --> 00:00:41,840
When should you actually write 
these tests? 

16
00:00:42,120 --> 00:00:44,320
And finally, we'll unpack the 
benefits, why it actually 

17
00:00:44,320 --> 00:00:46,720
matters. 
And I think connecting it to the

18
00:00:46,720 --> 00:00:49,760
bigger picture, it's really 
fundamental if you want to build

19
00:00:49,760 --> 00:00:53,120
software that's robust, you 
know, reliable stuff that 

20
00:00:53,120 --> 00:00:55,880
actually works for users without
constant headaches. 

21
00:00:56,280 --> 00:00:59,160
The real question is, how do we 
make sure complex systems are 

22
00:00:59,160 --> 00:01:03,120
high quality and maintainable? 
Unit testing is a big piece of 

23
00:01:03,120 --> 00:01:05,720
that puzzle. 
It turns theory into practice. 

24
00:01:05,720 --> 00:01:07,600
Well put. 
OK, so let's start where the 

25
00:01:07,600 --> 00:01:10,720
source does Section 8, point 
2.1, laying out some key 

26
00:01:10,720 --> 00:01:14,040
definitions. 
We need these building blocks 

27
00:01:14,040 --> 00:01:15,240
first. 
Makes sense. 

28
00:01:15,240 --> 00:01:19,160
First up, test method. 
What is that really? 

29
00:01:19,400 --> 00:01:22,400
Well, it's basically the 
smallest piece of a unit test. 

30
00:01:22,800 --> 00:01:26,120
Usually it's a method in your 
code marked with something like 

31
00:01:26,280 --> 00:01:28,440
a test, you know, in frameworks 
like Joint, right? 

32
00:01:28,880 --> 00:01:33,880
And its whole job is to check 
one tiny specific bit of 

33
00:01:33,880 --> 00:01:36,360
functionality, right? 
Like looking at one specific 

34
00:01:36,360 --> 00:01:39,040
behavior under a microscope to 
make sure it does exactly what 

35
00:01:39,040 --> 00:01:40,520
you expect. 
Very precise. 

36
00:01:40,680 --> 00:01:42,840
And building on that, you have 
the fixture. 

37
00:01:42,840 --> 00:01:44,400
This is about setting the stage 
right. 

38
00:01:44,400 --> 00:01:47,960
All the programs state the data,
the objects, whatever setup is 

39
00:01:47,960 --> 00:01:50,640
needed before your test method 
or maybe several test methods 

40
00:01:50,880 --> 00:01:53,040
can even run. 
OK, so the starting conditions. 

41
00:01:53,040 --> 00:01:54,840
Exactly. 
And the name fixture, it's kind 

42
00:01:54,840 --> 00:01:56,480
of interesting. 
The source points out it 

43
00:01:56,480 --> 00:01:57,880
actually comes from 
manufacturing. 

44
00:01:57,880 --> 00:01:58,720
Oh, really? 
Yeah. 

45
00:01:58,720 --> 00:02:02,080
Like a physical jig or tool that
holds a workpiece steady while 

46
00:02:02,080 --> 00:02:05,320
it's being worked on in code. 
The fixture sort of fixes the 

47
00:02:05,320 --> 00:02:08,080
state, sets up that consistent, 
controlled environment so your 

48
00:02:08,080 --> 00:02:11,200
test results are reliable. 
Without a good fixture, things 

49
00:02:11,200 --> 00:02:14,160
can get unpredictable. 
That manufacturing analogy 

50
00:02:14,160 --> 00:02:17,200
actually makes a lot of sense. 
OK, next term test case. 

51
00:02:18,160 --> 00:02:22,160
Now the source mentions G unit 5
point Nella specifically here in

52
00:02:22,160 --> 00:02:24,720
June. 
It a test case is basically a 

53
00:02:24,720 --> 00:02:27,080
class right? 
A container that holds a bunch 

54
00:02:27,080 --> 00:02:28,760
of related test methods. 
That's it. 

55
00:02:29,560 --> 00:02:32,960
The name itself, Test Case, is 
apparently a bit historical from

56
00:02:32,960 --> 00:02:35,600
older Joe Unit versions where 
you inherited from a test case 

57
00:02:35,600 --> 00:02:37,840
class. 
But today think of it as just a 

58
00:02:37,840 --> 00:02:41,400
logical grouping, like all the 
tests for your user login class 

59
00:02:41,600 --> 00:02:43,720
might live inside a user login 
test class. 

60
00:02:43,720 --> 00:02:45,920
That class is the test case. 
Makes sense. 

61
00:02:45,920 --> 00:02:48,640
It keeps things organized and 
that leads naturally to test 

62
00:02:48,640 --> 00:02:50,600
suite. 
Suite sounds like more than one.

63
00:02:50,680 --> 00:02:52,320
Exactly. 
A test suite is just a 

64
00:02:52,320 --> 00:02:55,600
collection of these test cases. 
You group several test cases 

65
00:02:55,600 --> 00:02:58,520
together, maybe all the tests 
for a whole feature or a module,

66
00:02:58,720 --> 00:03:01,360
and the testing runs them all as
one batch. 

67
00:03:01,680 --> 00:03:04,200
So you can check a larger part 
of the system all at once. 

68
00:03:04,240 --> 00:03:06,920
Precisely, it gives you that 
broader automated check on the 

69
00:03:06,920 --> 00:03:09,040
overall health of that section 
of code. 

70
00:03:09,040 --> 00:03:12,040
Got it. 
And one more key term here, 

71
00:03:12,040 --> 00:03:15,120
though it's a bit broader. 
System under test. 

72
00:03:15,160 --> 00:03:18,080
Yeah, SUT. 
Ah yes, AC. 

73
00:03:18,120 --> 00:03:21,760
This just means whatever 
specific piece of code you're 

74
00:03:21,760 --> 00:03:24,480
actually testing right now. 
Could be one method, could be a 

75
00:03:24,480 --> 00:03:26,680
whole class, maybe a small 
component. 

76
00:03:26,840 --> 00:03:29,160
Yeah, it's the target. 
You'll also hear people call it 

77
00:03:29,240 --> 00:03:31,040
production code. 
Right, production code. 

78
00:03:31,280 --> 00:03:33,960
Because it's the real code 
you're building the stuff that's

79
00:03:33,960 --> 00:03:37,560
supposed to eventually go live. 
Defining your SUT clearly is 

80
00:03:37,560 --> 00:03:40,080
pretty important. 
It sets the scope for your test.

81
00:03:40,080 --> 00:03:41,760
Absolutely. 
OK, so we've got those 

82
00:03:41,760 --> 00:03:44,760
definitions nailed down. 
Test method fixture, Test case, 

83
00:03:45,120 --> 00:03:48,360
Test suite, SUT. 
But knowing what they are is one

84
00:03:48,360 --> 00:03:50,200
thing. 
The really practical question is

85
00:03:50,200 --> 00:03:53,880
when do you write them? 
Yeah, the timing is crucial, and

86
00:03:53,880 --> 00:03:56,200
there are really 2 main schools 
of thought here. 

87
00:03:56,440 --> 00:04:00,640
The first one, maybe the most 
common, is writing tests after 

88
00:04:00,640 --> 00:04:02,520
you've built a small bit of 
functionality. 

89
00:04:02,920 --> 00:04:06,680
So you write some code, maybe a 
method or two, and then right 

90
00:04:06,680 --> 00:04:09,360
away you write the test to prove
that code works. 

91
00:04:09,440 --> 00:04:13,160
So it's code, then test, then 
more code, then more test, like 

92
00:04:13,160 --> 00:04:14,280
a cycle. 
Exactly. 

93
00:04:14,280 --> 00:04:17,200
A little loop code, a bit test 
it, repeat. 

94
00:04:17,200 --> 00:04:19,000
You get constant feedback as you
go. 

95
00:04:19,000 --> 00:04:20,399
OK. 
That sounds logical. 

96
00:04:20,399 --> 00:04:22,920
What's the other way? 
The other way is, well, it's 

97
00:04:23,040 --> 00:04:25,000
kind of a paradigm shift for 
some people. 

98
00:04:25,000 --> 00:04:27,760
It's called Test Driven 
Development or TDD. 

99
00:04:27,760 --> 00:04:28,840
TDD right? 
Are they? 

100
00:04:29,000 --> 00:04:30,920
With TDD, you flip it 
completely. 

101
00:04:30,920 --> 00:04:34,040
You write the test first, before
you write any of the actual 

102
00:04:34,040 --> 00:04:36,000
production code that the test is
for. 

103
00:04:36,120 --> 00:04:38,480
Wait, so you write a test for 
code that doesn't exist yet? 

104
00:04:38,480 --> 00:04:41,040
Yep. 
And naturally that test is going

105
00:04:41,040 --> 00:04:43,240
to fail, right? 
Because there's nothing in there

106
00:04:43,240 --> 00:04:45,480
to make it pass. 
That's the red light in the TDD 

107
00:04:45,480 --> 00:04:47,320
cycle. 
Red because it fails OK. 

108
00:04:47,440 --> 00:04:51,240
Then only then do you write the 
absolute minimum amount of 

109
00:04:51,240 --> 00:04:54,600
production code needed to make 
that specific failing test pass 

110
00:04:54,960 --> 00:04:56,800
just enough to get the green 
light OK. 

111
00:04:57,000 --> 00:04:59,400
Red to green. 
And once it's green, you can 

112
00:04:59,400 --> 00:05:02,680
clean up the code refactor 
knowing your test will instantly

113
00:05:02,680 --> 00:05:05,560
tell you if you broke anything. 
That's the refactor step. 

114
00:05:05,560 --> 00:05:08,080
So it's this constant red green 
refactor cycle. 

115
00:05:08,720 --> 00:05:12,880
That sounds disciplined. 
Writing the test first forces 

116
00:05:12,880 --> 00:05:15,480
you to think about the 
requirements upfront, I guess. 

117
00:05:15,640 --> 00:05:19,160
Precisely, it forces clarity 
about what the code should do 

118
00:05:19,160 --> 00:05:20,960
before you write it. 
Now, the source mentioned 

119
00:05:20,960 --> 00:05:23,600
something really interesting, 
especially if you've ever, you 

120
00:05:23,600 --> 00:05:25,040
know, pulled your hair out over 
a bug. 

121
00:05:26,400 --> 00:05:28,960
Yes, bug fixing. 
It is a really good time to 

122
00:05:28,960 --> 00:05:31,160
write a test is when you find a 
bug. 

123
00:05:31,880 --> 00:05:35,800
The idea is, before you even try
to fix it, write a new test that

124
00:05:35,800 --> 00:05:37,560
specifically makes the bug 
happen. 

125
00:05:37,680 --> 00:05:39,880
Reproduces the failure scenario.
Exactly. 

126
00:05:39,920 --> 00:05:43,120
That test will fail, obviously, 
and you go fix the bug. 

127
00:05:43,440 --> 00:05:46,160
And if you fixed it right, that 
test you just wrote should now 

128
00:05:46,160 --> 00:05:48,240
pass. 
And the beauty is that test 

129
00:05:48,240 --> 00:05:50,080
stays in your test suite 
forever. 

130
00:05:50,160 --> 00:05:51,360
Right. 
It becomes like a permanent 

131
00:05:51,360 --> 00:05:54,120
guard against that specific bug 
ever coming back. 

132
00:05:54,360 --> 00:05:56,840
It's way better than just 
sticking in temporary print 

133
00:05:56,840 --> 00:06:01,160
statements to debug, you know? 
Oh totally, those system dot out

134
00:06:01,160 --> 00:06:03,320
print and calls, they get 
removed. 

135
00:06:03,920 --> 00:06:07,680
The test is a lasting asset. 
It prevents regressions for that

136
00:06:07,680 --> 00:06:10,240
specific issue. 
So that's a great tactic. 

137
00:06:10,600 --> 00:06:13,880
Now what about what not to do 
regarding timing? 

138
00:06:14,200 --> 00:06:16,840
Well, the big no no, according 
to the source and just general 

139
00:06:16,840 --> 00:06:20,040
experience, is leaving testing 
until the very end. 

140
00:06:20,400 --> 00:06:23,400
Like saving it all up for the 
end of a project or the end of a

141
00:06:23,400 --> 00:06:25,200
Sprint. 
Kind of like how things used to 

142
00:06:25,200 --> 00:06:26,960
happen in older waterfall 
models. 

143
00:06:26,960 --> 00:06:29,040
Why is that so bad? 
Seems like you'd have a whole 

144
00:06:29,040 --> 00:06:31,640
picture then. 
The problem is, reality hits. 

145
00:06:32,200 --> 00:06:34,760
You're rushing to finish. 
New features are demanding 

146
00:06:34,760 --> 00:06:37,920
attention because the system 
looks like it's working, and the

147
00:06:37,920 --> 00:06:41,240
tests either get done hastily 
and poorly, or worse, they just 

148
00:06:41,240 --> 00:06:43,800
don't get written at all. 
Quality suffers. 

149
00:06:44,240 --> 00:06:47,480
OK, short changed at the end. 
Yeah, and this ties into another

150
00:06:47,480 --> 00:06:49,480
point. 
Who should actually write these 

151
00:06:49,480 --> 00:06:50,720
tests? 
Good question. 

152
00:06:51,120 --> 00:06:53,760
A separate QA team. 
The source strongly recommends 

153
00:06:53,760 --> 00:06:55,760
against that. 
Actually, the developer who 

154
00:06:55,760 --> 00:06:59,080
writes the production code for a
class should also write its unit

155
00:06:59,080 --> 00:07:00,040
tests. 
Really. 

156
00:07:00,360 --> 00:07:02,120
Why is that? 
Because they have the deepest 

157
00:07:02,200 --> 00:07:04,280
just understanding of how that 
code is supposed to work. 

158
00:07:04,280 --> 00:07:06,040
It's edge cases where it might 
break. 

159
00:07:06,440 --> 00:07:09,000
Outsourcing it or giving it to 
another team, you lose that 

160
00:07:09,000 --> 00:07:11,960
intimate knowledge. 
Keeping it together fosters 

161
00:07:11,960 --> 00:07:15,640
ownership and usually leads to 
better, more meaningful tests. 

162
00:07:15,640 --> 00:07:18,680
OK, that makes sense. 
Developer ownership for quality,

163
00:07:18,760 --> 00:07:19,960
right? 
All right, so we've got the 

164
00:07:19,960 --> 00:07:22,240
definitions. 
We've talked about when to write

165
00:07:22,240 --> 00:07:25,800
tests, ideally early and often, 
maybe TDD, definitely when 

166
00:07:25,800 --> 00:07:28,040
fixing bugs and not at the very 
end. 

167
00:07:28,040 --> 00:07:31,440
Now, the payoff. 
Why bother with all this? 

168
00:07:31,440 --> 00:07:34,000
What are the real benefits for, 
you know, the project, the 

169
00:07:34,000 --> 00:07:36,800
users, the business? 
This is where it really clicks. 

170
00:07:36,800 --> 00:07:39,840
I think the number one benefit, 
the most obvious one, is 

171
00:07:39,840 --> 00:07:43,600
catching bugs early, way before 
the code gets out into the. 

172
00:07:43,600 --> 00:07:45,720
Wild and early means cheaper to 
fix, right? 

173
00:07:45,720 --> 00:07:48,280
Massively cheaper. 
Think about fixing a typo on a 

174
00:07:48,280 --> 00:07:50,880
blueprint versus recalling 
thousands of cars. 

175
00:07:51,280 --> 00:07:54,080
Finding a bug with a unit test 
during development costs, 

176
00:07:54,160 --> 00:07:55,800
relatively speaking, almost 
nothing. 

177
00:07:56,080 --> 00:07:58,320
Finding that same bug after a 
lease? 

178
00:07:58,560 --> 00:08:01,720
That can cost a fortune not just
in fixing it, but in lost 

179
00:08:01,720 --> 00:08:05,760
reputation, user trust, support,
calls, everything. 

180
00:08:05,920 --> 00:08:08,840
Yeah, OK. 
That's a huge financial and 

181
00:08:08,840 --> 00:08:11,160
reputational driver. 
Absolutely, it's like the 

182
00:08:11,160 --> 00:08:13,960
cheapest insurance policy you 
can buy for your software 

183
00:08:13,960 --> 00:08:16,160
quality. 
OK, so catching new bugs early, 

184
00:08:16,360 --> 00:08:19,160
what else? 
The other huge one is acting as 

185
00:08:19,160 --> 00:08:21,560
a safety net against regression.
Regressions. 

186
00:08:21,560 --> 00:08:24,400
That's when you fix something or
add a new feature and it 

187
00:08:24,400 --> 00:08:25,680
accidentally breaks something 
else. 

188
00:08:25,680 --> 00:08:27,400
That used to work, right? 
Exactly. 

189
00:08:27,400 --> 00:08:31,400
That code regresses goes 
backward in quality because a 

190
00:08:31,400 --> 00:08:33,760
change had unintended side 
effects. 

191
00:08:33,799 --> 00:08:36,200
It's incredibly common in 
complex systems. 

192
00:08:36,200 --> 00:08:37,559
In frustrating. 
Totally. 

193
00:08:37,880 --> 00:08:40,440
But good unit tests are your 
defense here. 

194
00:08:40,840 --> 00:08:44,440
After you make any change a fix,
a new future, even just cleaning

195
00:08:44,440 --> 00:08:46,400
up code, you run your whole test
suite. 

196
00:08:46,840 --> 00:08:49,240
If you accidentally broke 
something elsewhere, even in a 

197
00:08:49,240 --> 00:08:52,560
totally unrelated part of the 
code, a test over there will 

198
00:08:52,560 --> 00:08:54,880
fail. 
So it flags the collateral 

199
00:08:54,880 --> 00:08:56,920
damage immediately. 
Immediately before it gets 

200
00:08:56,920 --> 00:08:58,520
checked in, before it affects 
anyone else. 

201
00:08:58,520 --> 00:09:01,680
It gives developers confidence 
to make changes, to refactor, to

202
00:09:01,680 --> 00:09:04,560
improve the code, because they 
know they have this automated 

203
00:09:04,560 --> 00:09:06,600
system constantly watching their
back. 

204
00:09:06,640 --> 00:09:09,080
That sounds incredibly valuable,
a safety net. 

205
00:09:09,160 --> 00:09:10,880
It really is. 
And there's another benefit may 

206
00:09:10,880 --> 00:09:13,360
be less obvious. 
The source mentions 

207
00:09:13,360 --> 00:09:16,400
documentation. 
Yes, this is often overlooked. 

208
00:09:16,880 --> 00:09:21,040
Unit tests act as living 
executable documentation for 

209
00:09:21,040 --> 00:09:22,600
your code. 
How so? 

210
00:09:23,040 --> 00:09:25,600
Well, think about trying to 
understand a piece of code you 

211
00:09:25,600 --> 00:09:27,760
didn't write or haven't seen in 
six months. 

212
00:09:28,000 --> 00:09:31,200
Instead of just reading the code
itself or relying on potentially

213
00:09:31,200 --> 00:09:34,600
outdated comments, you can look 
at the tests for that code. 

214
00:09:34,920 --> 00:09:37,720
The tests show you how the code 
is intended to be used. 

215
00:09:37,840 --> 00:09:40,600
What inputs does it expect? 
What should the output look 

216
00:09:40,600 --> 00:09:42,440
like? 
How does it handle weird edge 

217
00:09:42,440 --> 00:09:45,440
cases or errors? 
The tests demonstrate the 

218
00:09:45,440 --> 00:09:48,440
intended behavior in concrete, 
runnable examples. 

219
00:09:48,640 --> 00:09:51,160
So the tests are like examples 
of how to use the code 

220
00:09:51,160 --> 00:09:52,360
correctly. 
Exactly. 

221
00:09:52,640 --> 00:09:55,080
The source even suggests that 
before you start maintaining 

222
00:09:55,080 --> 00:09:56,840
some code, you should read its 
tests first. 

223
00:09:56,840 --> 00:09:58,720
It gives you a functional 
specification. 

224
00:09:59,560 --> 00:10:01,280
Living documentation. 
I like that. 

225
00:10:01,640 --> 00:10:03,640
OK, so these benefits sound 
great in theory. 

226
00:10:03,640 --> 00:10:06,280
Early bud catches regression 
safety net documentation. 

227
00:10:06,680 --> 00:10:10,080
But is this actually, you know, 
done in the real world, or is it

228
00:10:10,080 --> 00:10:12,920
just academic? 
Oh, it's very much real world. 

229
00:10:13,640 --> 00:10:16,280
The source points out that unit 
testing is probably the most 

230
00:10:16,280 --> 00:10:19,640
impactful and widely adopted 
practice that came out of agile 

231
00:10:19,640 --> 00:10:22,600
methodologies. 
Tons of companies, big and 

232
00:10:22,600 --> 00:10:24,920
small, rely heavily on unit 
tests. 

233
00:10:24,920 --> 00:10:27,520
Any specific examples? 
Yeah, the source gives a couple 

234
00:10:27,520 --> 00:10:29,480
of big ones. 
Google for instance. 

235
00:10:29,920 --> 00:10:32,040
OK, what? 
Do they do at Google? 

236
00:10:32,040 --> 00:10:35,320
Unit testing is like baked into 
the culture. 

237
00:10:35,320 --> 00:10:38,280
It's expected that all 
production code has unit tests. 

238
00:10:38,920 --> 00:10:41,640
Their code review tools actually
flag code if someone tries to 

239
00:10:41,640 --> 00:10:43,520
submit it without corresponding 
tests. 

240
00:10:43,640 --> 00:10:46,040
Wow, so it's enforced 
systemically? 

241
00:10:46,040 --> 00:10:49,520
Seriously enforced, it shows a 
massive commitment to quality 

242
00:10:49,520 --> 00:10:52,320
control right at the source. 
OK, Google's a big one. 

243
00:10:52,600 --> 00:10:55,480
Any others? 
Facebook or Meta now is another 

244
00:10:55,480 --> 00:10:57,680
example. 
Their engineers write unit tests

245
00:10:57,680 --> 00:10:59,440
for their new code standard 
practice. 

246
00:10:59,760 --> 00:11:03,640
But critically, all code, before
it can be committed and pushed 

247
00:11:03,640 --> 00:11:07,360
into the main code base, must 
automatically pass the entire 

248
00:11:07,360 --> 00:11:09,560
accumulated suite of progression
tests. 

249
00:11:09,680 --> 00:11:12,320
So it's part of the pipeline. 
You literally can't merge your 

250
00:11:12,320 --> 00:11:14,080
code if it breaks existing 
tests. 

251
00:11:14,280 --> 00:11:16,080
Exactly. 
It's built right into their 

252
00:11:16,080 --> 00:11:18,840
workflow. 
Imagine the scale of their code 

253
00:11:18,840 --> 00:11:20,680
and how many changes happen 
daily. 

254
00:11:21,160 --> 00:11:24,880
That automated safety net is 
essential for them to move fast 

255
00:11:25,080 --> 00:11:28,160
without constantly breaking 
things for billions of users. 

256
00:11:28,160 --> 00:11:30,480
That makes total sense. 
You need that automation at 

257
00:11:30,480 --> 00:11:31,680
scale. 
You really do. 

258
00:11:32,320 --> 00:11:35,440
OK, so let's wrap this U. 
We've kind of unpacked the core 

259
00:11:35,440 --> 00:11:37,240
ideas, right? 
We looked at the definitions, 

260
00:11:37,240 --> 00:11:39,920
test method, fixture, test case,
test suite, SUT. 

261
00:11:40,040 --> 00:11:43,800
We talked about when to write 
tests, ideally continuously. 

262
00:11:44,000 --> 00:11:47,640
TDD is an option definitely for 
bugs, not at the end, and we've 

263
00:11:47,640 --> 00:11:50,480
seen the huge benefits. 
Yeah, catching bugs early, 

264
00:11:50,480 --> 00:11:53,520
preventing those painful 
regressions and even acting as 

265
00:11:53,520 --> 00:11:55,840
useful up to date documentation 
it. 

266
00:11:55,840 --> 00:11:59,160
Really makes it clear why this 
isn't just a nice to have, yeah,

267
00:11:59,160 --> 00:12:02,240
but pretty fundamental in modern
software development, and why 

268
00:12:02,240 --> 00:12:04,800
places like Google and Meta 
build it right into their core 

269
00:12:04,800 --> 00:12:06,440
processes. 
Couldn't agree more. 

270
00:12:06,480 --> 00:12:08,440
Well, thank you for joining us 
on this deep dive. 

271
00:12:08,480 --> 00:12:11,800
We really hope this gave you a 
much clearer picture of unit 

272
00:12:11,800 --> 00:12:14,760
testing and why it matters. 
Thank you for diving in with us.