-
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.
