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.