1
00:00:00,120 --> 00:00:03,920
OK, let's unpack this. 
Have you ever heard of a concept

2
00:00:04,440 --> 00:00:09,040
that, at first glance, seems to 
turn everything you know on its 

3
00:00:09,040 --> 00:00:12,720
head, but then you realize it's 
actually incredibly insightful? 

4
00:00:13,120 --> 00:00:15,520
Well, that's precisely what 
we're diving into today, 

5
00:00:16,079 --> 00:00:18,960
something called testdriven 
development or TDD. 

6
00:00:19,280 --> 00:00:21,760
It's a practice that really 
challenges the conventional 

7
00:00:21,760 --> 00:00:24,600
wisdom of, you know, software 
creation. 

8
00:00:24,640 --> 00:00:26,080
It's truly fascinating, isn't 
it? 

9
00:00:26,080 --> 00:00:29,400
TDD fundamentally flips the 
traditional software development

10
00:00:29,400 --> 00:00:31,400
process. 
I mean, instead of starting with

11
00:00:31,400 --> 00:00:33,440
the functional code, you begin 
with the tests, right? 

12
00:00:33,680 --> 00:00:36,840
It's a profound shift in mindset
that has reshaped how many 

13
00:00:36,840 --> 00:00:40,080
successful teams approach their 
work, leading to some, well, 

14
00:00:40,080 --> 00:00:43,000
surprising benefits. 
Our mission in this deep dive is

15
00:00:43,000 --> 00:00:46,480
to give you a clear, concise 
shortcut to understanding this 

16
00:00:46,480 --> 00:00:48,960
intriguing approach. 
We'll explore why so many 

17
00:00:48,960 --> 00:00:52,120
developers swear by it, how it 
works in practice, and what 

18
00:00:52,120 --> 00:00:55,160
truly makes it a game changer 
for building not just working 

19
00:00:55,160 --> 00:00:59,280
software, but robust, well 
designed systems that stand the 

20
00:00:59,280 --> 00:01:01,880
test of time. 
Putting a handle on the Y is 

21
00:01:01,880 --> 00:01:03,920
key. 
Think of it as gaining an unfair

22
00:01:03,920 --> 00:01:07,320
advantage in understanding a 
powerful development philosophy.

23
00:01:08,400 --> 00:01:10,680
So let's jump right into that 
core idea. 

24
00:01:12,480 --> 00:01:16,080
Test Driven Development, or TDD,
isn't just some random 

25
00:01:16,080 --> 00:01:18,240
technique. 
It's one of the foundational 

26
00:01:18,240 --> 00:01:21,600
programming practices that 
emerge from Extreme Programming,

27
00:01:21,920 --> 00:01:26,000
or XP, which is a highly 
influential Agile software 

28
00:01:26,000 --> 00:01:29,160
development framework. 
That's right, XP really pushed a

29
00:01:29,160 --> 00:01:32,960
lot of these ideas forward. 
And the initial concept, like we

30
00:01:32,960 --> 00:01:36,280
hinted, can feel truly counter 
intuitive, almost backward. 

31
00:01:36,720 --> 00:01:39,000
Imagine this. 
You're tasked with building a 

32
00:01:39,000 --> 00:01:42,120
brand new feature for an 
application with TDD. 

33
00:01:42,240 --> 00:01:45,000
You don't start by writing the 
actual code for that feature. 

34
00:01:45,360 --> 00:01:47,560
Instead, you start by writing 
the unit test for it. 

35
00:01:47,800 --> 00:01:50,240
It's like preparing a pop quiz 
for yourself before you've even 

36
00:01:50,240 --> 00:01:52,120
opened the textbook. 
That's a good way to put. 

37
00:01:52,120 --> 00:01:54,520
It that's why it's also very 
commonly known as test first 

38
00:01:54,520 --> 00:01:55,640
development. 
Exactly. 

39
00:01:55,640 --> 00:01:58,280
And this initial step, which 
might feel like putting the cart

40
00:01:58,280 --> 00:02:02,600
before the horse, is deliberate.
When you write that test, it's 

41
00:02:02,600 --> 00:02:04,400
going to fail. 
It has to, right? 

42
00:02:04,440 --> 00:02:06,000
Right. 
Because the code isn't there. 

43
00:02:06,160 --> 00:02:09,479
Because the code you intend to 
test doesn't exist yet, or it 

44
00:02:09,479 --> 00:02:11,600
certainly doesn't perform the 
functionality of the test 

45
00:02:11,600 --> 00:02:14,360
expects. 
This initial failure isn't a 

46
00:02:14,360 --> 00:02:18,000
mistake, it's the first crucial 
step in the TDD workflow, A 

47
00:02:18,320 --> 00:02:21,080
deliberate entry into what we 
call the red state. 

48
00:02:21,560 --> 00:02:25,360
Once you have that failing test,
your immediate laser focus goal 

49
00:02:25,360 --> 00:02:29,040
is to write just enough code. 
And often we mean just enough, 

50
00:02:29,240 --> 00:02:32,520
sometimes even the most trivial 
implementation to make that 

51
00:02:32,520 --> 00:02:35,720
specific test pass. 
Really just the bare minimum. 

52
00:02:35,720 --> 00:02:38,400
Just enough. 
It's about achieving a small, 

53
00:02:38,400 --> 00:02:41,400
focused victory. 
Then, once it's passing, you 

54
00:02:41,400 --> 00:02:44,560
enter a refinement phase, making
the code fully functional and 

55
00:02:44,560 --> 00:02:47,080
robust. 
And finally, crucially, you 

56
00:02:47,080 --> 00:02:48,480
refactor it. 
Refactor OK. 

57
00:02:48,560 --> 00:02:51,480
This means you improve its 
internal design readability and 

58
00:02:51,480 --> 00:02:54,280
maintainability, ensuring it 
adheres to those good design 

59
00:02:54,280 --> 00:02:56,200
principles and patterns we all 
strive for. 

60
00:02:56,280 --> 00:02:58,840
That seems like a really 
disciplined way to work, but why

61
00:02:58,840 --> 00:03:01,720
embrace that initial failure? 
What's the hidden power in 

62
00:03:01,720 --> 00:03:04,240
starting in the red where your 
code isn't even even functional 

63
00:03:04,240 --> 00:03:06,240
yet? 
It's all about clarity and 

64
00:03:06,240 --> 00:03:09,160
intention. 
That failing test acts as a 

65
00:03:09,160 --> 00:03:11,840
precise executable 
specification. 

66
00:03:12,080 --> 00:03:15,080
You're defining exactly what you
expect the code to do before you

67
00:03:15,080 --> 00:03:17,800
write it. 
OK, so it forces you to think it

68
00:03:17,800 --> 00:03:19,320
through 1st. 
Precisely. 

69
00:03:19,480 --> 00:03:22,320
It eliminates ambiguity and 
ensures you're building exactly 

70
00:03:22,320 --> 00:03:24,520
what's needed. 
It's kind of like a contract you

71
00:03:24,520 --> 00:03:26,320
write with yourself or your 
future self. 

72
00:03:26,640 --> 00:03:30,160
That brings us to why TDD is far
more than just a way to write 

73
00:03:30,160 --> 00:03:32,840
tests. 
It's not just about did it work,

74
00:03:33,280 --> 00:03:36,320
it's about fundamentally 
shifting how we build and think 

75
00:03:36,320 --> 00:03:39,360
about software, leading to 
breakthroughs most developers 

76
00:03:39,400 --> 00:03:42,680
only dream of. 
The sources pinpoint 3 

77
00:03:42,680 --> 00:03:46,280
significant objectives that when
you combine them, reveal TDD's 

78
00:03:46,280 --> 00:03:49,680
true game changing power. 
Objectives that go right to the 

79
00:03:49,680 --> 00:03:52,360
heart of good software 
engineering and truly elevate 

80
00:03:52,360 --> 00:03:54,720
your development process. 
The first objective is 

81
00:03:54,720 --> 00:03:57,640
deceptively simple but 
incredibly powerful. 

82
00:03:58,160 --> 00:04:01,160
TDD virtually eliminates the 
possibility of developers simply

83
00:04:01,160 --> 00:04:03,680
forgetting to write tests. 
Which happens a. 

84
00:04:03,720 --> 00:04:05,400
Lot We've all been there, 
haven't we? 

85
00:04:05,880 --> 00:04:08,960
You're rushing to push a feature
out, maybe on a tight deadline, 

86
00:04:09,200 --> 00:04:10,880
and testing feels like an 
afterthought. 

87
00:04:11,440 --> 00:04:14,960
You promise yourself you'll get 
to it later, but later often 

88
00:04:14,960 --> 00:04:16,720
never comes. 
Or it comes when something 

89
00:04:16,720 --> 00:04:17,920
breaks. 
Exactly. 

90
00:04:18,040 --> 00:04:21,120
Or if it does, it's usually when
a bug is reported and you're 

91
00:04:21,120 --> 00:04:25,120
scrambling to replicate it. 
With TDD, testing isn't an 

92
00:04:25,120 --> 00:04:27,920
afterthought. 
It's the first activity for any 

93
00:04:27,920 --> 00:04:31,360
programming task, whether you're
squashing A stubborn bug or 

94
00:04:31,360 --> 00:04:33,600
building an entirely new feature
from scratch. 

95
00:04:33,600 --> 00:04:36,600
It's baked in from the start. 
Because you start with a test, 

96
00:04:36,880 --> 00:04:40,360
it becomes genuinely difficult, 
almost impossible, to postpone 

97
00:04:40,360 --> 00:04:42,760
writing it. 
This inherent built in 

98
00:04:42,760 --> 00:04:45,760
discipline leads to dramatically
higher test coverage. 

99
00:04:45,840 --> 00:04:49,360
Yeah, the data backs this up. 
The data from teams adopting TDD

100
00:04:49,360 --> 00:04:53,440
consistently shows test coverage
soaring, often exceeding 90%. 

101
00:04:53,600 --> 00:04:56,360
Think about that for a moment. 
90% test coverage means you have

102
00:04:56,360 --> 00:04:59,680
an incredibly high confidence 
level that your code works as 

103
00:04:59,680 --> 00:05:03,000
intended, significantly reducing
the chances of costly, 

104
00:05:03,000 --> 00:05:05,440
embarrassing bugs making it into
production. 

105
00:05:05,440 --> 00:05:08,320
It saves countless hours of 
debugging down the line, and it 

106
00:05:08,320 --> 00:05:10,080
really does. 
Then there's the second 

107
00:05:10,080 --> 00:05:13,960
objective, which is a natural, 
almost organic benefit of that 

108
00:05:13,960 --> 00:05:18,480
inverted workflow. 
TDD encourages writing code with

109
00:05:18,480 --> 00:05:20,320
incredibly high testability. 
This is. 

110
00:05:20,320 --> 00:05:22,920
Huge for code quality. 
This is where the magic really 

111
00:05:22,920 --> 00:05:25,200
starts to happen. 
For code quality, consider this.

112
00:05:25,640 --> 00:05:30,840
You, the developer, first write 
the test T and only then 

113
00:05:30,840 --> 00:05:33,320
implement the Class C It's meant
to test. 

114
00:05:33,640 --> 00:05:36,280
What happens if you start 
designing Class C in a way 

115
00:05:36,280 --> 00:05:39,760
that's difficult to test? 
You feel the pain immediately. 

116
00:05:39,760 --> 00:05:42,000
You're going to immediately feel
that friction when you're trying

117
00:05:42,000 --> 00:05:44,800
to write the test for it. 
The test will be clunky, hard to

118
00:05:44,800 --> 00:05:47,200
set up, maybe require complex 
dependencies. 

119
00:05:47,720 --> 00:05:51,360
This immediate, almost painful 
feedback loop forces you to 

120
00:05:51,360 --> 00:05:53,240
design Class C better from the 
start. 

121
00:05:53,800 --> 00:05:56,600
You'll naturally gravitate 
towards simler interfaces, fewer

122
00:05:56,600 --> 00:05:59,680
dependencies, and more modular 
components because, well, 

123
00:05:59,680 --> 00:06:01,200
they're simly easier to test. 
It's. 

124
00:06:01,200 --> 00:06:04,000
Designed by necessity, you could
say, and it works remarkably 

125
00:06:04,000 --> 00:06:05,360
well. 
And this leads us directly to 

126
00:06:05,360 --> 00:06:07,960
the third and perhaps most 
profound objective. 

127
00:06:08,560 --> 00:06:11,720
TDD functions primarily as a 
powerful design practice, not 

128
00:06:11,720 --> 00:06:14,120
just a testing practice. 
Yeah, this one often surprises 

129
00:06:14,120 --> 00:06:15,760
people. 
This is often the most 

130
00:06:15,760 --> 00:06:18,200
surprising benefit for those new
to TDD. 

131
00:06:18,360 --> 00:06:22,240
If we connect this to the bigger
picture, this aspect of TDD is 

132
00:06:22,320 --> 00:06:25,880
absolutely crucial for building 
robust, maintainable software. 

133
00:06:26,360 --> 00:06:29,120
By starting with the tests, 
developers inherently place 

134
00:06:29,120 --> 00:06:32,200
themselves in the shoes of a 
user of the class they're about 

135
00:06:32,200 --> 00:06:34,520
to build. 
OK, like putting on a different?

136
00:06:34,520 --> 00:06:38,120
Hat exactly the test itself. 
That very first piece of code 

137
00:06:38,120 --> 00:06:41,480
you write for a new component 
acts as a client for that class.

138
00:06:41,840 --> 00:06:44,880
It's calling methods interacting
with the interface you're 

139
00:06:44,880 --> 00:06:48,400
designing right now. 
I see this immediate user 

140
00:06:48,400 --> 00:06:51,240
centric perspective naturally 
guides developers toward 

141
00:06:51,240 --> 00:06:54,120
defining A simpler, cleaner 
interface for the class. 

142
00:06:54,680 --> 00:06:57,280
You'll find yourself using more 
readable method names because 

143
00:06:57,280 --> 00:06:59,480
you're having to use them 
immediately in the test. 

144
00:06:59,600 --> 00:07:01,320
Makes sense? 
You'll work to minimize the 

145
00:07:01,320 --> 00:07:04,280
number of parameters needed for 
methods, ensuring they're easier

146
00:07:04,280 --> 00:07:06,200
to call and less prone to 
errors. 

147
00:07:06,800 --> 00:07:10,280
And you'll adhere to many other 
fundamental best practices in 

148
00:07:10,280 --> 00:07:13,720
software design, like the Single
Responsibility Principle, 

149
00:07:13,720 --> 00:07:17,080
because honestly, a class with 
too many responsibilities is 

150
00:07:17,280 --> 00:07:20,480
inherently harder to test. 
Right, it gets messy quickly. 

151
00:07:20,720 --> 00:07:23,400
It effectively forces you to 
think about how others will 

152
00:07:23,400 --> 00:07:26,440
consume your code before you've 
even written the implementation 

153
00:07:26,440 --> 00:07:29,680
details, leading to inherently 
better architecture. 

154
00:07:29,880 --> 00:07:32,600
It's like an internal design 
critique built right into your 

155
00:07:32,600 --> 00:07:35,560
workflow. 
That intuitive shift makes so 

156
00:07:35,560 --> 00:07:38,160
much sense, that idea of 
designing from the outside in. 

157
00:07:39,200 --> 00:07:43,120
But how does this test first 
approach actually play out 

158
00:07:43,120 --> 00:07:46,640
day-to-day for a developer? 
What's the practical loop they 

159
00:07:46,640 --> 00:07:48,960
follow? 
I've heard it's visualized as 3 

160
00:07:48,960 --> 00:07:50,960
distinct states. 
Can you walk us through them? 

161
00:07:51,160 --> 00:07:54,200
Absolutely. 
When you're working with TDD, 

162
00:07:54,200 --> 00:07:57,280
developers follow a continuous, 
almost meditative cycle that's 

163
00:07:57,280 --> 00:08:01,000
often visualized as 3 distinct 
states, much like a traffic 

164
00:08:01,000 --> 00:08:04,360
light guiding your progress. 
Red, green and refactor. 

165
00:08:04,360 --> 00:08:07,120
Red green refactor OK. 
It's a tight iterative loop you 

166
00:08:07,120 --> 00:08:09,960
repeat for every small piece of 
functionality you add. 

167
00:08:10,280 --> 00:08:12,720
Let's breakdown those states, 
starting with the red state. 

168
00:08:13,080 --> 00:08:15,840
This is your initial goal, 
writing a test that fails. 

169
00:08:15,880 --> 00:08:17,360
Right, the counterintuitive 
part. 

170
00:08:17,360 --> 00:08:19,160
OK. 
It sounds counterproductive, 

171
00:08:19,160 --> 00:08:21,520
yeah, like you're deliberately 
causing a problem. 

172
00:08:22,080 --> 00:08:26,480
But this failing test serves as 
your crystal clear executable 

173
00:08:26,480 --> 00:08:30,520
specification for the feature or
behavior you're about to 

174
00:08:30,520 --> 00:08:32,559
implement. 
It tells you exactly what 

175
00:08:32,559 --> 00:08:34,760
behavior you expect the code to 
exhibit. 

176
00:08:35,520 --> 00:08:37,440
So the failure tells you what 
success looks like. 

177
00:08:37,440 --> 00:08:41,720
Precisely in this RedState, 
developers are also actively 

178
00:08:41,720 --> 00:08:44,240
thinking about the interface of 
the class from a user's 

179
00:08:44,240 --> 00:08:47,080
perspective, defining how it 
will be interacted with. 

180
00:08:47,560 --> 00:08:51,040
Now, to even get the test to run
and fail properly, not just fail

181
00:08:51,040 --> 00:08:53,720
because of a compilation error, 
the class you're testing must at

182
00:08:53,720 --> 00:08:56,560
least compile. 
OK, so you need something. 

183
00:08:56,600 --> 00:08:59,080
You need something, yeah. 
This means you have to define 

184
00:08:59,080 --> 00:09:01,400
the class name and the 
signatures of its methods, even 

185
00:09:01,400 --> 00:09:04,360
if they contain no actual logic 
yet, just empty shells. 

186
00:09:04,920 --> 00:09:07,920
This minimal setup is part of 
achieving that first small 

187
00:09:07,920 --> 00:09:10,640
victory of a compiling failing 
test. 

188
00:09:10,680 --> 00:09:12,760
Got it. 
It's a very satisfying red light

189
00:09:12,760 --> 00:09:14,920
that screams, OK, now you know 
what to build. 

190
00:09:14,920 --> 00:09:17,840
Once you've achieved that 
satisfying red test, the very 

191
00:09:17,840 --> 00:09:19,800
next goal is to reach the green 
state. 

192
00:09:20,080 --> 00:09:22,120
This is where you make that 
failing test pass. 

193
00:09:22,320 --> 00:09:24,720
Right, time to fix the problem 
you just created. 

194
00:09:25,040 --> 00:09:28,400
Now, crucially, this isn't about
writing the perfect complete 

195
00:09:28,400 --> 00:09:32,080
implementation all at once. 
The genius of TDD lies in its 

196
00:09:32,080 --> 00:09:35,600
baby steps principle. 
You write just enough code to 

197
00:09:35,600 --> 00:09:38,080
make that specific test pass. 
Just that one. 

198
00:09:38,280 --> 00:09:42,040
Initially, your code might only 
work partially, or it might even

199
00:09:42,040 --> 00:09:46,240
return a hard coded constant 
value that makes that specific 

200
00:09:46,240 --> 00:09:49,280
test green. 
Seriously, like just return true

201
00:09:49,280 --> 00:09:51,760
or 42? 
Sometimes, yeah, if that's what 

202
00:09:51,760 --> 00:09:53,800
the test needs to pass at that 
exact moment. 

203
00:09:54,040 --> 00:09:55,640
The point is to get to green 
quickly. 

204
00:09:55,640 --> 00:09:58,960
For that one test, you resist 
the urge to add extra 

205
00:09:58,960 --> 00:10:00,520
functionality or make it 
perfect. 

206
00:10:00,840 --> 00:10:02,560
You simply make the current test
pass. 

207
00:10:03,080 --> 00:10:06,680
This rapid feedback loop builds 
confidence and maintains focus. 

208
00:10:06,720 --> 00:10:08,200
OK, that makes sense. 
Small wins. 

209
00:10:08,560 --> 00:10:11,240
And finally, once your test is 
passing, you're in that green 

210
00:10:11,240 --> 00:10:13,400
state. 
Developers then proactively seek

211
00:10:13,400 --> 00:10:16,000
opportunities to enter the 
refactor state, cleaning up 

212
00:10:16,080 --> 00:10:19,040
exactly this is where the long 
term health of your code base 

213
00:10:19,040 --> 00:10:21,760
truly benefits. 
You step back and look at both 

214
00:10:21,760 --> 00:10:23,840
the new class code and the test 
code itself. 

215
00:10:23,840 --> 00:10:26,600
You assess its quality. 
Can it be made cleaner, More 

216
00:10:26,600 --> 00:10:28,480
readable? 
More understandable? 

217
00:10:28,640 --> 00:10:31,040
Easier to maintain for yourself 
or future developers. 

218
00:10:31,040 --> 00:10:32,480
So you're improving the 
internals? 

219
00:10:32,480 --> 00:10:34,880
Right. 
This might involve checking for 

220
00:10:34,880 --> 00:10:38,360
duplicate code that could be 
consolidated, identifying overly

221
00:10:38,360 --> 00:10:40,920
large methods that could be 
broken down into smaller, more 

222
00:10:40,920 --> 00:10:44,760
focused ones, or even evaluating
whether certain methods would be

223
00:10:44,760 --> 00:10:46,520
better placed in different 
classes. 

224
00:10:47,000 --> 00:10:50,080
The key is that you refactor 
only after you have a passing 

225
00:10:50,080 --> 00:10:52,160
test. 
That's the safety net. 

226
00:10:52,160 --> 00:10:54,560
That's the safety net. 
This makes refactoring 

227
00:10:54,560 --> 00:10:57,480
incredibly safe, because if you 
accidentally break something, 

228
00:10:57,480 --> 00:11:00,440
your tests will immediately turn
red, letting you know you've 

229
00:11:00,440 --> 00:11:03,080
introduced A regression bang. 
Instant feedback. 

230
00:11:03,400 --> 00:11:06,880
This quality assessment is a 
fundamental part of the TDD 

231
00:11:06,880 --> 00:11:10,320
cycle, making sure that not only
does the code work, but it's 

232
00:11:10,320 --> 00:11:12,400
also well designed and 
sustainable. 

233
00:11:13,000 --> 00:11:15,000
After refactoring you have a 
choice. 

234
00:11:15,200 --> 00:11:17,440
Either conclude the current 
process if the feature is 

235
00:11:17,440 --> 00:11:21,000
complete and well designed, or 
you restart the cycle red green 

236
00:11:21,000 --> 00:11:24,400
refactor to implement another 
small feature or address another

237
00:11:24,400 --> 00:11:26,880
aspect of the design. 
It's a continuous loop. 

238
00:11:27,600 --> 00:11:30,720
To really make this concrete, 
let's walk through a simulated 

239
00:11:30,720 --> 00:11:34,800
programming session using TDD 
with a simple relatable example,

240
00:11:35,200 --> 00:11:37,040
building a virtual bookstore 
system. 

241
00:11:37,040 --> 00:11:39,400
OK, good idea. 
Imagine you're tasked with 

242
00:11:39,400 --> 00:11:41,640
creating the back end for an 
online bookstore. 

243
00:11:42,040 --> 00:11:45,760
For our purposes, this system 
involves 2 main components, a 

244
00:11:45,760 --> 00:11:48,240
book class which holds basic 
information like the book's 

245
00:11:48,240 --> 00:11:50,760
title, its ISBN number and its 
price. 

246
00:11:50,760 --> 00:11:53,280
Standard stuff. 
Then we have the shopping cart 

247
00:11:53,280 --> 00:11:55,360
class. 
This shopping cart needs to be 

248
00:11:55,360 --> 00:11:58,040
able to store the books a 
customer wants to buy, calculate

249
00:11:58,040 --> 00:12:01,000
the total price of all items 
currently in the cart, and even 

250
00:12:01,000 --> 00:12:03,560
allow customers to remove a book
if they change their mind. 

251
00:12:03,720 --> 00:12:06,120
Got it. 
So following the TDD cycle, the 

252
00:12:06,120 --> 00:12:08,840
very first step would be to get 
to that RedState for our 

253
00:12:08,840 --> 00:12:11,000
shopping cart. 
Right, start with the test. 

254
00:12:11,120 --> 00:12:13,760
This means before you write any 
of the actual shopping cart 

255
00:12:13,760 --> 00:12:17,000
logic, we write a test. 
We might create a test method 

256
00:12:17,320 --> 00:12:21,600
called Test Ad Jet Total. 
This test would try to add 2 

257
00:12:21,600 --> 00:12:26,120
book objects, let's say the Art 
of War priced at $10 and Clean 

258
00:12:26,120 --> 00:12:30,320
Code at $20 to a shopping cart. 
Then the test would assert that 

259
00:12:30,320 --> 00:12:33,240
the total price in the cart is 
exactly $30. 

260
00:12:33,960 --> 00:12:36,640
Now, initially this test simply 
won't compile because neither 

261
00:12:36,640 --> 00:12:38,920
the book nor the shopping cart 
classes exist yet. 

262
00:12:39,040 --> 00:12:40,360
Makes sense, They're not 
defined. 

263
00:12:41,120 --> 00:12:44,320
To achieve the red state where 
the test compiles, runs and 

264
00:12:44,320 --> 00:12:47,160
fails as expected, developers 
would provide a bare minimum, 

265
00:12:47,160 --> 00:12:50,160
almost placeholder 
implementation for both book and

266
00:12:50,160 --> 00:12:52,160
shopping cart. 
For Book you define its 

267
00:12:52,160 --> 00:12:54,280
attributes and maybe a basic 
constructor. 

268
00:12:54,280 --> 00:12:56,440
Just the structure. 
Just the structure for shopping 

269
00:12:56,440 --> 00:12:57,480
cart. 
You might just have an empty 

270
00:12:57,480 --> 00:13:00,040
constructor, an AD method that 
does nothing yet, and a get 

271
00:13:00,040 --> 00:13:03,280
total method that simply returns
0.0. 

272
00:13:03,640 --> 00:13:06,080
So it returns the wrong value. 
Exactly. 

273
00:13:06,360 --> 00:13:10,000
This bare bones setup is enough 
to make the test compile, but 

274
00:13:10,000 --> 00:13:13,800
because get total returns 0, the
test will correctly fail its 

275
00:13:13,800 --> 00:13:17,920
assertion, giving us that small 
victory of a compiling failing 

276
00:13:17,920 --> 00:13:22,320
test that now acts as a clear 
executable specification. 

277
00:13:22,880 --> 00:13:25,640
Make get total return the sum of
added books. 

278
00:13:25,640 --> 00:13:28,880
OK, read achieved. 
After achieving that satisfying 

279
00:13:28,880 --> 00:13:32,600
RedState, the focus immediately 
shifts to getting to green. 

280
00:13:33,120 --> 00:13:36,000
This is about making that 
failing test edge a total test 

281
00:13:36,000 --> 00:13:37,440
pass. 
Time for the fix. 

282
00:13:37,440 --> 00:13:40,120
Following the baby steps 
principle, a quick initial 

283
00:13:40,120 --> 00:13:42,680
implementation in shopping cart 
might have its get total method 

284
00:13:42,680 --> 00:13:45,280
simply return 30 point O. 
Just hard code it. 

285
00:13:45,280 --> 00:13:47,640
Yeah, yes, it's right. 
It just returns the specific 

286
00:13:47,640 --> 00:13:49,760
value needed to make that one 
test pass. 

287
00:13:50,040 --> 00:13:52,200
Even if it's not a real 
calculation that works for any 

288
00:13:52,200 --> 00:13:54,120
books, it's a quick win to get 
to green. 

289
00:13:54,120 --> 00:13:56,840
OK, interesting tactic. 
Then once that particular test 

290
00:13:56,840 --> 00:13:59,560
is green, you move to providing 
a more realistic and robust 

291
00:13:59,560 --> 00:14:01,600
implementation. 
For our shopping cart. 

292
00:14:01,600 --> 00:14:04,160
This would mean actually 
including say a private list or 

293
00:14:04,160 --> 00:14:05,960
collection to store the book 
items added. 

294
00:14:05,960 --> 00:14:08,840
Right, a container. 
And maybe an internal attribute 

295
00:14:08,840 --> 00:14:10,920
to accurately track the total 
value. 

296
00:14:11,120 --> 00:14:13,960
The add method would then 
correctly add books to this list

297
00:14:14,120 --> 00:14:16,320
and dynamically update that 
running total. 

298
00:14:16,640 --> 00:14:20,000
And the get total method would 
return this actual calculated 

299
00:14:20,000 --> 00:14:23,880
total from the list of books. 
So the real logic comes in after

300
00:14:23,880 --> 00:14:26,680
the initial make it past step. 
Exactly. 

301
00:14:27,240 --> 00:14:30,880
Iterative refinement is core to 
getting to a correct passing 

302
00:14:30,880 --> 00:14:33,600
green state, one small test at a
time. 

303
00:14:33,680 --> 00:14:36,240
And once we're firmly in that 
green state, with the shopping 

304
00:14:36,240 --> 00:14:39,600
cart code successfully making 
our test pass, the next crucial 

305
00:14:39,600 --> 00:14:41,720
step is the refactor state. 
Polish it up. 

306
00:14:42,480 --> 00:14:45,200
This is where we ask ourselves, 
how can we make this code more 

307
00:14:45,200 --> 00:14:49,080
readable, more understandable, 
and easier to maintain for 

308
00:14:49,080 --> 00:14:52,080
anyone who comes across it, 
including ourselves, in like 6 

309
00:14:52,080 --> 00:14:53,880
months, Yeah. 
Future you will appreciate. 

310
00:14:53,880 --> 00:14:55,840
It definitely in our bookstore 
example. 

311
00:14:55,840 --> 00:14:59,400
One excellent refactoring idea 
that might arise relates to the 

312
00:14:59,400 --> 00:15:02,440
Book class. 
Initially, maybe for simplicity,

313
00:15:02,680 --> 00:15:06,520
it's fields like title, price 
and ISBN might have been 

314
00:15:06,520 --> 00:15:09,520
declared as public. 
OK, easy to access, but maybe 

315
00:15:09,520 --> 00:15:10,720
not ideal. 
Right. 

316
00:15:11,160 --> 00:15:13,920
Refactoring would involve 
changing them to private and 

317
00:15:13,920 --> 00:15:17,040
then implementing public getter 
methods to access them. 

318
00:15:17,480 --> 00:15:20,600
This is crucial for information 
hiding. 

319
00:15:20,600 --> 00:15:23,200
It means the Book object 
controls its own data, 

320
00:15:23,440 --> 00:15:26,160
preventing other parts of the 
system from accidentally or 

321
00:15:26,160 --> 00:15:28,280
incorrectly modifying its 
internal state. 

322
00:15:28,480 --> 00:15:30,440
So it protects the books data 
integrity. 

323
00:15:30,480 --> 00:15:33,840
Precisely this makes the book 
class more robust, more 

324
00:15:33,840 --> 00:15:36,720
predictable, and less prone to 
accidental misuse. 

325
00:15:37,160 --> 00:15:40,160
This kind of thoughtful quality 
assessment, making sure the code

326
00:15:40,160 --> 00:15:43,400
is not just functional but also 
elegantly designed, is a 

327
00:15:43,400 --> 00:15:46,400
fundamental and continuous part 
of the TDD cycle. 

328
00:15:46,560 --> 00:15:48,720
And there you have it, a deep 
dive into Test Driven 

329
00:15:48,720 --> 00:15:50,800
Development. 
What started as a counter 

330
00:15:50,800 --> 00:15:53,960
intuitive ideal almost backward 
reveals itself through this 

331
00:15:53,960 --> 00:15:57,520
powerful red green re factor 
cycle to be a remarkably 

332
00:15:57,520 --> 00:15:59,600
disciplined and powerful way to 
build software. 

333
00:16:00,120 --> 00:16:02,880
It's truly fascinating to see 
how a simple shift in order can 

334
00:16:02,880 --> 00:16:05,560
have such a profound impact on 
quality and design. 

335
00:16:05,840 --> 00:16:09,440
It truly transforms how we 
approach building software, not 

336
00:16:09,440 --> 00:16:12,840
just ensuring it works, but 
ensuring it's well designed, 

337
00:16:12,840 --> 00:16:15,840
robust and maintainable from the
very first line of code. 

338
00:16:16,480 --> 00:16:20,240
It fundamentally changes the 
developer's mindset from fixing 

339
00:16:20,240 --> 00:16:23,480
problems to preventing them. 
So next time you're faced with a

340
00:16:23,480 --> 00:16:26,880
complex coding challenge, maybe 
consider if starting with the 

341
00:16:26,880 --> 00:16:30,680
red might just be the fastest, 
most effective path to a truly 

342
00:16:30,680 --> 00:16:33,080
green and beautifully refactored
solution. 

343
00:16:33,320 --> 00:16:35,680
It's a testament to how often 
the most powerful solutions 

344
00:16:35,680 --> 00:16:37,640
emerge from simply changing our 
perspective. 

345
00:16:37,720 --> 00:16:39,800
Well said. 
Thank you for joining us on this

346
00:16:39,800 --> 00:16:41,080
deep dive into TDD.