1
00:00:00,000 --> 00:00:03,877
So this, in chapter five, the testing
overview. This is, this is Brian

2
00:00:03,877 --> 00:00:07,807
Kernighan, the author, one of the Bell
Labs, heroes who the author of the

3
00:00:07,807 --> 00:00:12,055
Kernighan and Ritchie book on [inaudible]
that probably most of you had. The, and

4
00:00:12,055 --> 00:00:16,410
it's, if you read it a couple, you can get
it. Debugging is twice as hard as writing

5
00:00:16,410 --> 00:00:20,606
code in the [inaudible]. Therefore, it's
twice as hard, right? So therefore, if you

6
00:00:20,606 --> 00:00:24,802
write the cleverest code the first time,
you're never gonna be able to debug it,

7
00:00:24,802 --> 00:00:30,067
'cause it's twice as hard. Alright, this
one, this is Dystra test and you've gotta

8
00:00:30,067 --> 00:00:36,088
fill in the blank. Testing can never
demonstrate the. Absence of air is only

9
00:00:36,088 --> 00:00:41,042
there. Presence, right? Well that's,
that's been around for a long time, and

10
00:00:41,042 --> 00:00:46,700
just gotta keep that in mind. Here is an
article that came out a year and a half

11
00:00:46,700 --> 00:00:51,922
ago, and it says why are things expensive.
And you can see here that their study is

12
00:00:51,922 --> 00:00:56,825
it's not that there's bugs and [inaudible]
in design, it's just lousy testing

13
00:00:56,825 --> 00:01:02,110
features, lousy, lousy testing processes
are reasons that there's, there's so many

14
00:01:02,110 --> 00:01:07,013
bugs in code. And it says here that
completely automated testing environments

15
00:01:07,013 --> 00:01:11,534
are rare. This was a year and a half ago.
Still, we're just twenty, twelve percent

16
00:01:11,534 --> 00:01:16,707
of software [inaudible] organizations have
fully automated testing systems. Ten

17
00:01:16,707 --> 00:01:21,023
percent do all testing manually. Right? So
you write the test. You look at the

18
00:01:21,023 --> 00:01:25,225
output. You write the test. Look at the
output. See any mistakes? Okay. So, wow,

19
00:01:25,225 --> 00:01:29,852
can't believe that, that, that's still
true. That's not true here. [laugh]. You

20
00:01:29,852 --> 00:01:35,086
know? For agile before the hand, you have
a separate quality assurance team. So you

21
00:01:35,086 --> 00:01:40,133
have all these phases and separate groups
of people. So, Marge, somehow, the quality

22
00:01:40,133 --> 00:01:44,805
assurance team was supposed to insert
quality in your code. [laugh]. Or make

23
00:01:44,805 --> 00:01:49,727
sure that you, you have quality in your
code. With Agile, it's part of everything

24
00:01:49,727 --> 00:01:54,260
we do. We're testing continuously. Every
week, we bring out new code. You're

25
00:01:54,260 --> 00:01:58,888
responsible for testing your code, not
somebody else. And the tools are highly

26
00:01:58,888 --> 00:02:03,816
[inaudible] so unlike that, that statement
that was done before. And so what the

27
00:02:03,816 --> 00:02:08,444
argument here in the [inaudible] the
actual manifesto is that if with a good

28
00:02:08,444 --> 00:02:13,493
process we'll get soft quality rather than
there's a specific group that's supposed

29
00:02:13,493 --> 00:02:20,141
to insure it that they're gonna beat you
up if you don't have it. So. Bdd and TDD

30
00:02:20,141 --> 00:02:25,636
was I said earlier. The phrase behavior
driven design was inspired by some people

31
00:02:25,636 --> 00:02:30,859
getting confused about test driven
development. Here we're testing acceptance

32
00:02:30,859 --> 00:02:36,286
tests, integration tests, and trying to
capture the behavior. Tdd is gonna be step

33
00:02:36,286 --> 00:02:41,849
definitions and actually write unit tests
and function tests, before you write the

34
00:02:41,849 --> 00:02:47,208
code. So that's the. So the good news is,
you're always gonna have the test up to

35
00:02:47,208 --> 00:02:52,485
date because you're writing the code or
even before it. So here's how they work

36
00:02:52,485 --> 00:02:56,992
together. Cucumbers describe the
[inaudible]. You, you start off writing

37
00:02:56,992 --> 00:03:01,564
the stories you want. They fail. Then it
invokes the implementations, the

38
00:03:01,564 --> 00:03:06,265
[inaudible] test. If it fails, you then,
you implement the methods that are

39
00:03:06,265 --> 00:03:10,901
missing. And then when it passes the
[inaudible] test, you keep iterating

40
00:03:10,901 --> 00:03:15,988
internally until you pass the [inaudible].
And then once you've implemented the

41
00:03:15,988 --> 00:03:20,946
feature properly, it, it will pass the
cucumber green step and you go back and

42
00:03:20,946 --> 00:03:23,200
keep going through the development.