1
00:00:00,040 --> 00:00:01,680
Welcome. 
Welcome back to the Deep Dive, 

2
00:00:02,160 --> 00:00:06,640
your go to shortcut for becoming
incredibly well informed. 

3
00:00:07,040 --> 00:00:08,960
Yeah, yeah, without drowning in 
research papers. 

4
00:00:09,000 --> 00:00:11,240
That's the goal. 
Today we're pulling back the 

5
00:00:11,240 --> 00:00:15,600
curtain on something pretty 
crucial, but maybe a bit 

6
00:00:15,600 --> 00:00:17,000
misunderstood in software 
development. 

7
00:00:17,480 --> 00:00:20,600
End to end tests. 
These aren't just some techie 

8
00:00:20,600 --> 00:00:24,160
detail, they're big reason why 
the apps you use daily actually 

9
00:00:24,160 --> 00:00:26,880
work like they're supposed to. 
Yeah, absolutely. 

10
00:00:27,080 --> 00:00:31,120
And understanding them well, it 
gives you a peek into why some 

11
00:00:31,120 --> 00:00:36,160
software feels solid and other 
stuff feels, well, flaky. 

12
00:00:36,280 --> 00:00:38,720
It really does. 
And when we say end to end, we 

13
00:00:38,720 --> 00:00:42,360
really mean simulating like a 
complete user journey start to 

14
00:00:42,360 --> 00:00:44,880
finish through the whole system.
Not just tiny pieces then. 

15
00:00:44,880 --> 00:00:47,480
No, not at all. 
These tests are designed to give

16
00:00:47,480 --> 00:00:49,880
you that big picture view, 
making sure everything hooks 

17
00:00:49,880 --> 00:00:52,560
together and works seamlessly 
from the moment you tap that 

18
00:00:52,560 --> 00:00:53,440
icon. 
Really. 

19
00:00:53,440 --> 00:00:54,240
OK. 
Right. 

20
00:00:54,240 --> 00:00:56,840
So let's unpack this. 
Our mission for this deep dive? 

21
00:00:57,160 --> 00:00:59,440
Figure out what these tests are,
why they're so, so important, 

22
00:00:59,600 --> 00:01:02,600
and then maybe get into some of 
the surprising complexities. 

23
00:01:02,600 --> 00:01:05,000
The trade-offs too. 
Exactly the trade-offs. 

24
00:01:05,120 --> 00:01:07,320
We'll use some real world 
examples to make it stick. 

25
00:01:07,960 --> 00:01:10,600
Get ready for a few aha moments 
hopefully. 

26
00:01:10,600 --> 00:01:13,960
Sounds good. 
So First things first, what are 

27
00:01:13,960 --> 00:01:16,120
end to end tests? 
You might hear other names 

28
00:01:16,120 --> 00:01:18,120
right, like system tests. 
System tests, yeah. 

29
00:01:18,120 --> 00:01:20,760
Or sometimes interface tests. 
The key thing is where they sit 

30
00:01:20,760 --> 00:01:23,720
in that, you know, testing 
period people talk about. 

31
00:01:23,720 --> 00:01:25,480
Right at the top. 
Yeah, the very tip. 

32
00:01:25,720 --> 00:01:29,160
You've got tons of tiny unit 
tests at the bottom checking 

33
00:01:29,160 --> 00:01:31,440
little bits of code. 
Super fast, those ones. 

34
00:01:31,440 --> 00:01:35,080
Then fewer integration tests 
checking out pieces work 

35
00:01:35,080 --> 00:01:37,400
together right? 
And then way fewer of these end 

36
00:01:37,400 --> 00:01:39,400
to end tests. 
And that position tells you 

37
00:01:39,400 --> 00:01:41,480
something. 
It's about scope, but also about

38
00:01:41,480 --> 00:01:44,720
how resource intensive they are.
Meaning meaning you just don't 

39
00:01:44,720 --> 00:01:46,440
run as many of them compared to 
the other. 

40
00:01:46,440 --> 00:01:48,840
OK. 
And their core purpose you said 

41
00:01:48,840 --> 00:01:50,800
simulating a user. 
Exactly. 

42
00:01:50,960 --> 00:01:55,040
Think about how you use an app. 
You log in, maybe click around, 

43
00:01:55,040 --> 00:01:58,640
fill out a form, hit submit. 
You expect something to happen. 

44
00:01:58,640 --> 00:02:02,400
An end to end test tries to 
automate that entire sequence, 

45
00:02:02,400 --> 00:02:04,120
the whole flow. 
So it's not just. 

46
00:02:04,120 --> 00:02:07,480
Does this button look right? 
No, it's does clicking this 

47
00:02:07,480 --> 00:02:10,600
button actually lead to the 
right data being saved and the 

48
00:02:10,600 --> 00:02:13,880
right screen showing up? 
It checks the whole chain 

49
00:02:13,880 --> 00:02:15,760
reaction through all the 
system's layers. 

50
00:02:15,880 --> 00:02:19,480
It's the ultimate Does this 
thing actually work for a real 

51
00:02:19,480 --> 00:02:21,680
person, Jack? 
You got it. 

52
00:02:21,680 --> 00:02:24,000
That's the essence of. 
It and here's that critical 

53
00:02:24,000 --> 00:02:25,640
point you mentioned, the 
resource thing. 

54
00:02:26,120 --> 00:02:29,320
These are the most resource 
intensive automated tests. 

55
00:02:29,440 --> 00:02:30,960
By far. 
And that's not just a 

56
00:02:30,960 --> 00:02:33,680
technicality, right? 
It has real consequences. 

57
00:02:33,680 --> 00:02:35,800
Absolutely. 
It means they take way more 

58
00:02:35,800 --> 00:02:38,160
effort to write. 
You often need special tools, 

59
00:02:38,160 --> 00:02:40,400
complex setups. 
And they take the longest to 

60
00:02:40,400 --> 00:02:42,160
actually run. 
Oh yeah, much longer. 

61
00:02:42,400 --> 00:02:44,080
Think about that factory 
analogy. 

62
00:02:44,240 --> 00:02:46,240
Checking 1 bolt? 
That's a unit test. 

63
00:02:46,560 --> 00:02:50,440
Quick checking if the whole car 
drives off the assembly line 

64
00:02:50,440 --> 00:02:54,080
perfectly after visiting every 
single station, that's your end 

65
00:02:54,080 --> 00:02:55,680
to end test. 
Takes way more time. 

66
00:02:55,680 --> 00:02:57,240
More. 
OK, that makes sense. 

67
00:02:57,240 --> 00:03:01,920
Let's make it even more concrete
case study one testing a web 

68
00:03:01,920 --> 00:03:03,520
system. 
People often use something 

69
00:03:03,520 --> 00:03:05,520
called Selenium. 
Selenium is a big one. 

70
00:03:05,520 --> 00:03:07,400
Yeah, very common for web 
testing. 

71
00:03:07,600 --> 00:03:10,600
So if you're building, say, an 
online store or social media 

72
00:03:10,600 --> 00:03:13,000
site, you need to know the whole
process works. 

73
00:03:13,120 --> 00:03:15,600
Signing up, finding a product, 
buying it. 

74
00:03:15,720 --> 00:03:18,480
All those critical user paths 
and Selenium lets you build 

75
00:03:18,480 --> 00:03:22,960
tests that act like, well, like 
robots using the website. 

76
00:03:22,960 --> 00:03:27,000
Like a very precise, maybe 
slightly literal robot user. 

77
00:03:27,000 --> 00:03:30,680
Pretty much these robots, these 
automated scripts do what a 

78
00:03:30,680 --> 00:03:32,840
human would. 
They open the browser. 

79
00:03:32,840 --> 00:03:35,520
Navigate Pages. 
Fill in forms, click the 

80
00:03:35,520 --> 00:03:38,880
buttons, wait for the page to 
load and then check if the 

81
00:03:38,880 --> 00:03:41,480
result is what they expected. 
So it's like scripting out. 

82
00:03:41,600 --> 00:03:45,080
OK computer, pretend you're a 
user, go here, do this, click 

83
00:03:45,080 --> 00:03:46,440
that. 
Now tell me if it worked. 

84
00:03:46,560 --> 00:03:48,760
That's exactly it. 
It's how you programmatically 

85
00:03:48,760 --> 00:03:51,280
verify that whole journey. 
We saw an example, right? 

86
00:03:51,560 --> 00:03:53,840
How about a Google search? 
Yeah, a simple but good one. 

87
00:03:54,280 --> 00:03:58,840
The test simulates someone using
Firefox going to Google, typing 

88
00:03:58,840 --> 00:04:01,520
software into the search bar, 
hitting enter. 

89
00:04:01,520 --> 00:04:04,000
Standard stuff. 
Right, but then the crucial 

90
00:04:04,000 --> 00:04:08,120
part, the test checks if the 
title of the search results page

91
00:04:08,120 --> 00:04:11,520
is exactly what it should be. 
So even that simple action tests

92
00:04:11,520 --> 00:04:15,800
a lot the browser, the website 
search function getting the 

93
00:04:15,800 --> 00:04:17,880
results back. 
The whole chain for that 

94
00:04:17,880 --> 00:04:20,920
specific task, but. 
It sounds straightforward, but 

95
00:04:20,920 --> 00:04:24,360
you mentioned challenges. 
Yes, it's fascinating because 

96
00:04:24,360 --> 00:04:27,440
while the idea is intuitive, 
actually building and 

97
00:04:27,440 --> 00:04:31,760
maintaining these tests is 
significantly harder than unit 

98
00:04:31,760 --> 00:04:34,080
tests, Even harder than 
integration tests sometimes. 

99
00:04:34,120 --> 00:04:35,600
Why is that? 
Well, think about it. 

100
00:04:35,880 --> 00:04:39,880
A unit test runs in a nice, 
clean, predictable environment. 

101
00:04:40,400 --> 00:04:43,200
Just code talking to code. 
Right, isolated. 

102
00:04:43,200 --> 00:04:45,120
An end to end test for a web 
app. 

103
00:04:45,120 --> 00:04:48,160
It's interacting with a real 
browser over the real Internet. 

104
00:04:48,160 --> 00:04:52,200
With a complex dynamic web page.
It's messier. 

105
00:04:52,200 --> 00:04:54,960
Unpredictable. 
Can be the source material 

106
00:04:54,960 --> 00:04:57,480
highlights a few things. 
First, the tool itself, like the

107
00:04:57,480 --> 00:05:00,080
Selenium API, the commands you 
use to control the browser. 

108
00:05:00,080 --> 00:05:02,560
It's just more complex. 
OK, you're telling it how to 

109
00:05:02,560 --> 00:05:05,720
deal with visual layouts, things
loading at different speeds, 

110
00:05:05,840 --> 00:05:08,840
mouse hovers. 
It's not just simple commands. 

111
00:05:08,840 --> 00:05:12,160
It's like giving instructions in
a busy changing room versus a 

112
00:05:12,160 --> 00:05:13,600
quiet library. 
Gotcha. 

113
00:05:13,680 --> 00:05:15,840
What else? 
Second, they have to handle what

114
00:05:15,840 --> 00:05:19,800
are called interface events, 
like maybe a button only appears

115
00:05:19,800 --> 00:05:21,560
after a three second animation 
finishes. 

116
00:05:22,000 --> 00:05:24,400
Right, a human would just wait. 
Exactly. 

117
00:05:24,600 --> 00:05:28,880
But the test script, if you 
don't explicitly tell it to wait

118
00:05:28,880 --> 00:05:33,000
for that button, it might try to
click too early, fail, and you 

119
00:05:33,000 --> 00:05:35,600
get a false alarm, a test 
failure that isn't a real bug. 

120
00:05:35,640 --> 00:05:37,320
So you have to program in 
patients basically. 

121
00:05:37,320 --> 00:05:40,440
You have to anticipate those 
delays, those dynamic changes, 

122
00:05:40,560 --> 00:05:42,720
time outs, elements appearing 
slowly. 

123
00:05:43,240 --> 00:05:44,520
It needs to handle that. 
OK. 

124
00:05:44,960 --> 00:05:47,640
And the third challenge you 
mentioned fragility. 

125
00:05:47,680 --> 00:05:50,840
Yes, this is a big one. 
They are much more susceptible 

126
00:05:50,840 --> 00:05:54,120
to breaking because of tiny, 
sometimes purely cosmetic 

127
00:05:54,120 --> 00:05:58,120
changes in the user interface. 
Like what the example given was 

128
00:05:58,120 --> 00:06:01,080
Google changing the internal 
name of its search input field 

129
00:06:01,440 --> 00:06:03,480
maybe from queue to search 
query? 

130
00:06:04,120 --> 00:06:06,440
And that breaks the test. 
Instantly, because the test 

131
00:06:06,440 --> 00:06:09,520
script is looking for an element
named Q and it's not there 

132
00:06:09,520 --> 00:06:12,480
anymore, the whole test fails, 
even though the search 

133
00:06:12,480 --> 00:06:14,680
functionality itself might be 
perfectly fine. 

134
00:06:14,680 --> 00:06:16,720
Wow, so even moving a button 
slightly it could? 

135
00:06:16,720 --> 00:06:20,680
Break it or changing its ID or 
its color if the test was 

136
00:06:20,680 --> 00:06:23,160
checking that. 
For some reason this makes them 

137
00:06:23,160 --> 00:06:25,960
brittle. 
You make a small UI tweak and 

138
00:06:25,960 --> 00:06:28,520
suddenly you have failing end to
end tests to fix. 

139
00:06:28,720 --> 00:06:31,560
That's a maintenance headache. 
I can imagine I heard about a 

140
00:06:31,560 --> 00:06:35,360
team chasing a failure that was 
just caused by a random pop up 

141
00:06:35,360 --> 00:06:39,200
ad blocking a button sometimes. 
Exactly that kind of real world 

142
00:06:39,200 --> 00:06:41,600
messiness. 
It's those unpredictable quirks 

143
00:06:41,600 --> 00:06:46,440
that make E2E web testing tough.
OK, so with all that, the 

144
00:06:46,440 --> 00:06:50,240
complexity, the fragility, the 
maintenance, are they actually 

145
00:06:50,240 --> 00:06:52,200
worth the hassle? 
That's the $1,000,000 question, 

146
00:06:52,200 --> 00:06:54,200
isn't it? 
And the answer is generally yes,

147
00:06:54,280 --> 00:06:55,960
but with caveats. 
It comes down to the 

148
00:06:55,960 --> 00:06:58,480
alternative, which is doing all 
that testing manually. 

149
00:06:58,880 --> 00:07:01,920
Imagine a person having to click
through every single possible 

150
00:07:01,920 --> 00:07:05,320
user journey on multiple 
browsers after every single tiny

151
00:07:05,320 --> 00:07:07,480
code change. 
That sounds awful, yeah. 

152
00:07:07,600 --> 00:07:10,400
Impossible to keep up. 
With it's incredibly slow, error

153
00:07:10,400 --> 00:07:13,960
prone and just doesn't scale. 
So compared to that, automated 

154
00:07:13,960 --> 00:07:17,160
end to end tests, despite their 
flaws, are still hugely 

155
00:07:17,160 --> 00:07:18,920
valuable. 
So it's a trade off. 

156
00:07:19,040 --> 00:07:22,400
They're expensive and brittle, 
but the alternative is worse for

157
00:07:22,400 --> 00:07:24,200
core functionality checks. 
Precisely. 

158
00:07:24,800 --> 00:07:27,600
The insight here is you use them
strategically. 

159
00:07:27,640 --> 00:07:30,800
You don't try to test every 
single obscure corner case with 

160
00:07:30,800 --> 00:07:32,560
an E to E test. 
That would cripple you. 

161
00:07:32,640 --> 00:07:34,560
You focus them. 
You focus them on the most 

162
00:07:34,560 --> 00:07:37,840
critical user paths. 
The login flow, the checkout 

163
00:07:37,840 --> 00:07:40,880
process, the main post, a 
message feature. 

164
00:07:41,120 --> 00:07:44,640
Let them be your final high 
level check that the most 

165
00:07:44,640 --> 00:07:47,560
important stuff hangs together. 
That final sanity check before 

166
00:07:47,560 --> 00:07:50,520
you release. 
Exactly, when you successfully 

167
00:07:50,520 --> 00:07:54,200
use an app online, chances are 
an E to E test ran that exact 

168
00:07:54,400 --> 00:07:57,240
same journey automatically to 
make sure it worked before it 

169
00:07:57,240 --> 00:07:59,480
got to you. 
That's their real impact, 

170
00:07:59,480 --> 00:08:02,240
providing that confidence in the
core experience. 

171
00:08:02,240 --> 00:08:05,680
OK, but what about systems 
without a visual front end? 

172
00:08:05,880 --> 00:08:08,840
Like behind the scenes stuff. 
Great question. 

173
00:08:08,840 --> 00:08:11,480
Yes, E2E tests are still very 
relevant and it actually 

174
00:08:11,480 --> 00:08:14,000
highlights different aspects. 
Let's take her second case 

175
00:08:14,000 --> 00:08:17,720
study, testing a compiler. 
A compiler like the software 

176
00:08:17,720 --> 00:08:21,240
that turns programming code into
something a computer can run. 

177
00:08:21,680 --> 00:08:23,160
How does that have an end to end
journey? 

178
00:08:23,160 --> 00:08:27,560
It does, and interestingly, the 
E2E tests here tend to be 

179
00:08:28,040 --> 00:08:30,760
conceptually simpler than for 
web systems. 

180
00:08:30,760 --> 00:08:31,600
Simpler. 
Why? 

181
00:08:31,960 --> 00:08:35,440
Because a compiler's interface 
isn't a graphical web page with 

182
00:08:35,440 --> 00:08:37,919
buttons and animations, it's 
typically much simpler. 

183
00:08:38,159 --> 00:08:40,360
It takes an input. 
File the source code. 

184
00:08:40,480 --> 00:08:42,360
Right, and it produces an 
output. 

185
00:08:42,360 --> 00:08:45,080
File the runnable program or 
maybe error messages. 

186
00:08:45,080 --> 00:08:47,320
Exactly. 
It's a file in, file out 

187
00:08:47,320 --> 00:08:50,240
process. 
Much more predictable, less 

188
00:08:50,240 --> 00:08:53,240
prone to those visual shifts 
that break web tests. 

189
00:08:53,320 --> 00:08:55,880
So how do you test that end to 
end well? 

190
00:08:55,880 --> 00:08:59,160
You create a collection of test 
programs, little pieces of code 

191
00:08:59,160 --> 00:09:00,960
written in the language the 
compiler is supposed to 

192
00:09:00,960 --> 00:09:03,160
understand. 
OK, and these test programs are 

193
00:09:03,160 --> 00:09:05,480
specifically designed to use 
different features of the 

194
00:09:05,480 --> 00:09:08,240
language. 
Loops, functions, weird edge 

195
00:09:08,240 --> 00:09:10,400
cases. 
To really exercise the compiler.

196
00:09:10,400 --> 00:09:13,720
Precisely, and for each test 
program you define exactly what 

197
00:09:13,720 --> 00:09:17,160
input it should receive when 
run, and crucially, what output 

198
00:09:17,160 --> 00:09:19,720
you expect it to produce. 
And the output format should be 

199
00:09:19,720 --> 00:09:21,600
simple. 
Ideally, yeah, like a list of 

200
00:09:21,680 --> 00:09:24,000
strings or numbers. 
Something easy for the test 

201
00:09:24,000 --> 00:09:26,480
script to automatically check 
against the actual output. 

202
00:09:26,680 --> 00:09:28,280
Got it. 
So what are the steps in the 

203
00:09:28,280 --> 00:09:31,320
test itself? 
Pretty straightforward mirroring

204
00:09:31,320 --> 00:09:34,200
what the compiler does. 
First, the test calls the 

205
00:09:34,200 --> 00:09:36,400
compiler to compile the test 
program P. 

206
00:09:36,640 --> 00:09:38,560
Does it build correctly? 
That's step one. 

207
00:09:38,680 --> 00:09:43,760
Step 2, if it compiles, the test
runs the resulting program using

208
00:09:43,760 --> 00:09:47,440
that predefined input data. 
And finally, Step 3. 

209
00:09:47,960 --> 00:09:51,200
The test captures the actual 
output from the running program 

210
00:09:51,440 --> 00:09:54,360
and compares it against the 
expected output you defined 

211
00:09:54,360 --> 00:09:56,680
earlier. 
And if they match, the test 

212
00:09:56,680 --> 00:09:57,720
passes. 
Correct. 

213
00:09:58,120 --> 00:10:02,920
And that whole sequence compile,
run, verify output is an end to 

214
00:10:02,920 --> 00:10:05,640
end test for the compiler 
because it uses all its major 

215
00:10:05,640 --> 00:10:08,760
parts, parsing the code, 
optimizing it, generating the 

216
00:10:08,760 --> 00:10:11,360
machine code and ensuring that 
code runs correctly. 

217
00:10:11,400 --> 00:10:13,440
It touches everything. 
The whole pipeline. 

218
00:10:13,960 --> 00:10:16,200
But there had to be challenges 
here too, right? 

219
00:10:16,200 --> 00:10:17,960
It sounds simpler, but maybe not
easy. 

220
00:10:18,000 --> 00:10:21,040
Oh, definitely challenges. 
The big one here compared to 

221
00:10:21,040 --> 00:10:23,880
unit tests is pinpointing why a 
test failed. 

222
00:10:24,360 --> 00:10:27,160
OK, so the test fails. 
Right, it tells you say program 

223
00:10:27,160 --> 00:10:29,040
X did not produce the expected 
output. 

224
00:10:29,040 --> 00:10:31,280
You know something is wrong in 
the compiler, but where? 

225
00:10:31,440 --> 00:10:33,200
Because the test covered the 
whole process. 

226
00:10:33,200 --> 00:10:35,240
Exactly. 
Was the bug in the parser, the 

227
00:10:35,240 --> 00:10:39,880
optimizer, the code generator? 
The end to end test itself often

228
00:10:39,880 --> 00:10:42,680
doesn't tell you, it just says 
the final result is wrong. 

229
00:10:42,840 --> 00:10:45,840
So debugging is harder. 
It's like knowing the car failed

230
00:10:45,840 --> 00:10:49,200
inspection but not knowing if it
was the brakes, emissions or 

231
00:10:49,200 --> 00:10:51,160
headlights without further 
checks. 

232
00:10:51,320 --> 00:10:52,960
That's a great analogy. 
You have to do more 

233
00:10:52,960 --> 00:10:56,800
investigation, maybe run more 
focused tests to trace that high

234
00:10:56,800 --> 00:10:59,880
level failure back to the 
specific buggy function within 

235
00:10:59,880 --> 00:11:02,720
the compiler's code. 
Unit tests are much better at 

236
00:11:02,720 --> 00:11:05,000
pinpointing the exact location 
of a bug. 

237
00:11:05,080 --> 00:11:07,880
That makes sense. 
Any other hidden challenges for 

238
00:11:07,880 --> 00:11:10,120
compilers? 
Well, actually creating all 

239
00:11:10,120 --> 00:11:13,200
those test programs can be a 
huge task in itself. 

240
00:11:13,520 --> 00:11:15,520
Think about a complex 
programming language. 

241
00:11:15,520 --> 00:11:18,560
You need test cases that cover 
every single feature, every 

242
00:11:18,560 --> 00:11:21,880
weird interaction between 
features, every possible syntax 

243
00:11:21,880 --> 00:11:25,000
error it should catch. 
That requires deep language 

244
00:11:25,000 --> 00:11:28,120
expertise and a lot of careful 
work just to create the inputs 

245
00:11:28,120 --> 00:11:30,720
and expected outputs. 
Just building the test suite is 

246
00:11:30,720 --> 00:11:33,360
a major project. 
It really can be. 

247
00:11:34,440 --> 00:11:37,880
Meticulously defining the 
correct output for hundreds or 

248
00:11:37,880 --> 00:11:41,880
thousands of intricate test 
programs is non trivial. 

249
00:11:42,680 --> 00:11:46,760
So wrapping this up then, yeah, 
end to end tests, whether for a 

250
00:11:46,760 --> 00:11:50,120
flashy website or a background 
compiler, are about simulating 

251
00:11:50,120 --> 00:11:52,600
that complete journey. 
That complete user interaction 

252
00:11:52,600 --> 00:11:55,040
or system process, yeah. 
They're powerful, they're 

253
00:11:55,040 --> 00:11:58,000
comprehensive, and they're 
really vital for making sure the

254
00:11:58,000 --> 00:12:01,400
whole system, not just the 
parts, actually works as 

255
00:12:01,400 --> 00:12:02,920
intended. 
They connect the dots. 

256
00:12:02,920 --> 00:12:04,560
Absolutely. 
And yes, they are resource 

257
00:12:04,560 --> 00:12:06,360
intensive. 
They take more effort, they run 

258
00:12:06,360 --> 00:12:10,000
slower, they can be brittle, 
especially with UIS, but their 

259
00:12:10,000 --> 00:12:13,800
ability to validate that entire 
system flow makes them pretty 

260
00:12:13,800 --> 00:12:16,040
much indispensable in modern 
software development. 

261
00:12:16,040 --> 00:12:18,600
They provide that final crucial 
layer of confidence. 

262
00:12:19,040 --> 00:12:21,200
The yes, this actually works for
a user check. 

263
00:12:21,200 --> 00:12:24,080
Couldn't set it better. 
They really are essential for 

264
00:12:24,080 --> 00:12:26,200
the reliable software we often 
take for granted. 

265
00:12:27,160 --> 00:12:29,400
Well, thanks for joining us on 
this deep dive into end to end 

266
00:12:29,400 --> 00:12:31,360
testing. 
We hope this gives you a clearer

267
00:12:31,360 --> 00:12:33,560
picture of why these tests 
matter so much.