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.