WEBVTT 00:00:00.000 --> 00:00:03.877 So this, in chapter five, the testing overview. This is, this is Brian 00:00:03.877 --> 00:00:07.807 Kernighan, the author, one of the Bell Labs, heroes who the author of the 00:00:07.807 --> 00:00:12.055 Kernighan and Ritchie book on [inaudible] that probably most of you had. The, and 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 00:00:16.410 --> 00:00:20.606 code in the [inaudible]. Therefore, it's twice as hard, right? So therefore, if you 00:00:20.606 --> 00:00:24.802 write the cleverest code the first time, you're never gonna be able to debug it, 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 00:00:30.067 --> 00:00:36.088 fill in the blank. Testing can never demonstrate the. Absence of air is only 00:00:36.088 --> 00:00:41.042 there. Presence, right? Well that's, that's been around for a long time, and 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 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 00:00:51.922 --> 00:00:56.825 it's not that there's bugs and [inaudible] in design, it's just lousy testing 00:00:56.825 --> 00:01:02.110 features, lousy, lousy testing processes are reasons that there's, there's so many 00:01:02.110 --> 00:01:07.013 bugs in code. And it says here that completely automated testing environments 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 00:01:11.534 --> 00:01:16.707 of software [inaudible] organizations have fully automated testing systems. Ten 00:01:16.707 --> 00:01:21.023 percent do all testing manually. Right? So you write the test. You look at the 00:01:21.023 --> 00:01:25.225 output. You write the test. Look at the output. See any mistakes? Okay. So, wow, 00:01:25.225 --> 00:01:29.852 can't believe that, that, that's still true. That's not true here. [laugh]. You 00:01:29.852 --> 00:01:35.086 know? For agile before the hand, you have a separate quality assurance team. So you 00:01:35.086 --> 00:01:40.133 have all these phases and separate groups of people. So, Marge, somehow, the quality 00:01:40.133 --> 00:01:44.805 assurance team was supposed to insert quality in your code. [laugh]. Or make 00:01:44.805 --> 00:01:49.727 sure that you, you have quality in your code. With Agile, it's part of everything 00:01:49.727 --> 00:01:54.260 we do. We're testing continuously. Every week, we bring out new code. You're 00:01:54.260 --> 00:01:58.888 responsible for testing your code, not somebody else. And the tools are highly 00:01:58.888 --> 00:02:03.816 [inaudible] so unlike that, that statement that was done before. And so what the 00:02:03.816 --> 00:02:08.444 argument here in the [inaudible] the actual manifesto is that if with a good 00:02:08.444 --> 00:02:13.493 process we'll get soft quality rather than there's a specific group that's supposed 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 00:02:20.141 --> 00:02:25.636 was I said earlier. The phrase behavior driven design was inspired by some people 00:02:25.636 --> 00:02:30.859 getting confused about test driven development. Here we're testing acceptance 00:02:30.859 --> 00:02:36.286 tests, integration tests, and trying to capture the behavior. Tdd is gonna be step 00:02:36.286 --> 00:02:41.849 definitions and actually write unit tests and function tests, before you write the 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 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 00:02:52.485 --> 00:02:56.992 together. Cucumbers describe the [inaudible]. You, you start off writing 00:02:56.992 --> 00:03:01.564 the stories you want. They fail. Then it invokes the implementations, the 00:03:01.564 --> 00:03:06.265 [inaudible] test. If it fails, you then, you implement the methods that are 00:03:06.265 --> 00:03:10.901 missing. And then when it passes the [inaudible] test, you keep iterating 00:03:10.901 --> 00:03:15.988 internally until you pass the [inaudible]. And then once you've implemented the 00:03:15.988 --> 00:03:20.946 feature properly, it, it will pass the cucumber green step and you go back and 00:03:20.946 --> 00:03:23.200 keep going through the development.