So this, in chapter five, the testing
overview. This is, this is Brian

Kernighan, the author, one of the Bell
Labs, heroes who the author of the

Kernighan and Ritchie book on [inaudible]
that probably most of you had. The, and

it's, if you read it a couple, you can get
it. Debugging is twice as hard as writing

code in the [inaudible]. Therefore, it's
twice as hard, right? So therefore, if you

write the cleverest code the first time,
you're never gonna be able to debug it,

'cause it's twice as hard. Alright, this
one, this is Dystra test and you've gotta

fill in the blank. Testing can never
demonstrate the. Absence of air is only

there. Presence, right? Well that's,
that's been around for a long time, and

just gotta keep that in mind. Here is an
article that came out a year and a half

ago, and it says why are things expensive.
And you can see here that their study is

it's not that there's bugs and [inaudible]
in design, it's just lousy testing

features, lousy, lousy testing processes
are reasons that there's, there's so many

bugs in code. And it says here that
completely automated testing environments

are rare. This was a year and a half ago.
Still, we're just twenty, twelve percent

of software [inaudible] organizations have
fully automated testing systems. Ten

percent do all testing manually. Right? So
you write the test. You look at the

output. You write the test. Look at the
output. See any mistakes? Okay. So, wow,

can't believe that, that, that's still
true. That's not true here. [laugh]. You

know? For agile before the hand, you have
a separate quality assurance team. So you

have all these phases and separate groups
of people. So, Marge, somehow, the quality

assurance team was supposed to insert
quality in your code. [laugh]. Or make

sure that you, you have quality in your
code. With Agile, it's part of everything

we do. We're testing continuously. Every
week, we bring out new code. You're

responsible for testing your code, not
somebody else. And the tools are highly

[inaudible] so unlike that, that statement
that was done before. And so what the

argument here in the [inaudible] the
actual manifesto is that if with a good

process we'll get soft quality rather than
there's a specific group that's supposed

to insure it that they're gonna beat you
up if you don't have it. So. Bdd and TDD

was I said earlier. The phrase behavior
driven design was inspired by some people

getting confused about test driven
development. Here we're testing acceptance

tests, integration tests, and trying to
capture the behavior. Tdd is gonna be step

definitions and actually write unit tests
and function tests, before you write the

code. So that's the. So the good news is,
you're always gonna have the test up to

date because you're writing the code or
even before it. So here's how they work

together. Cucumbers describe the
[inaudible]. You, you start off writing

the stories you want. They fail. Then it
invokes the implementations, the

[inaudible] test. If it fails, you then,
you implement the methods that are

missing. And then when it passes the
[inaudible] test, you keep iterating

internally until you pass the [inaudible].
And then once you've implemented the

feature properly, it, it will pass the
cucumber green step and you go back and

keep going through the development.