[Script Info] Title: [Events] Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text Dialogue: 0,0:00:00.00,0:00:03.88,Default,,0000,0000,0000,,So this, in chapter five, the testing\Noverview. This is, this is Brian Dialogue: 0,0:00:03.88,0:00:07.81,Default,,0000,0000,0000,,Kernighan, the author, one of the Bell\NLabs, heroes who the author of the Dialogue: 0,0:00:07.81,0:00:12.06,Default,,0000,0000,0000,,Kernighan and Ritchie book on [inaudible]\Nthat probably most of you had. The, and Dialogue: 0,0:00:12.06,0:00:16.41,Default,,0000,0000,0000,,it's, if you read it a couple, you can get\Nit. Debugging is twice as hard as writing Dialogue: 0,0:00:16.41,0:00:20.61,Default,,0000,0000,0000,,code in the [inaudible]. Therefore, it's\Ntwice as hard, right? So therefore, if you Dialogue: 0,0:00:20.61,0:00:24.80,Default,,0000,0000,0000,,write the cleverest code the first time,\Nyou're never gonna be able to debug it, Dialogue: 0,0:00:24.80,0:00:30.07,Default,,0000,0000,0000,,'cause it's twice as hard. Alright, this\None, this is Dystra test and you've gotta Dialogue: 0,0:00:30.07,0:00:36.09,Default,,0000,0000,0000,,fill in the blank. Testing can never\Ndemonstrate the. Absence of air is only Dialogue: 0,0:00:36.09,0:00:41.04,Default,,0000,0000,0000,,there. Presence, right? Well that's,\Nthat's been around for a long time, and Dialogue: 0,0:00:41.04,0:00:46.70,Default,,0000,0000,0000,,just gotta keep that in mind. Here is an\Narticle that came out a year and a half Dialogue: 0,0:00:46.70,0:00:51.92,Default,,0000,0000,0000,,ago, and it says why are things expensive.\NAnd you can see here that their study is Dialogue: 0,0:00:51.92,0:00:56.82,Default,,0000,0000,0000,,it's not that there's bugs and [inaudible]\Nin design, it's just lousy testing Dialogue: 0,0:00:56.82,0:01:02.11,Default,,0000,0000,0000,,features, lousy, lousy testing processes\Nare reasons that there's, there's so many Dialogue: 0,0:01:02.11,0:01:07.01,Default,,0000,0000,0000,,bugs in code. And it says here that\Ncompletely automated testing environments Dialogue: 0,0:01:07.01,0:01:11.53,Default,,0000,0000,0000,,are rare. This was a year and a half ago.\NStill, we're just twenty, twelve percent Dialogue: 0,0:01:11.53,0:01:16.71,Default,,0000,0000,0000,,of software [inaudible] organizations have\Nfully automated testing systems. Ten Dialogue: 0,0:01:16.71,0:01:21.02,Default,,0000,0000,0000,,percent do all testing manually. Right? So\Nyou write the test. You look at the Dialogue: 0,0:01:21.02,0:01:25.22,Default,,0000,0000,0000,,output. You write the test. Look at the\Noutput. See any mistakes? Okay. So, wow, Dialogue: 0,0:01:25.22,0:01:29.85,Default,,0000,0000,0000,,can't believe that, that, that's still\Ntrue. That's not true here. [laugh]. You Dialogue: 0,0:01:29.85,0:01:35.09,Default,,0000,0000,0000,,know? For agile before the hand, you have\Na separate quality assurance team. So you Dialogue: 0,0:01:35.09,0:01:40.13,Default,,0000,0000,0000,,have all these phases and separate groups\Nof people. So, Marge, somehow, the quality Dialogue: 0,0:01:40.13,0:01:44.80,Default,,0000,0000,0000,,assurance team was supposed to insert\Nquality in your code. [laugh]. Or make Dialogue: 0,0:01:44.80,0:01:49.73,Default,,0000,0000,0000,,sure that you, you have quality in your\Ncode. With Agile, it's part of everything Dialogue: 0,0:01:49.73,0:01:54.26,Default,,0000,0000,0000,,we do. We're testing continuously. Every\Nweek, we bring out new code. You're Dialogue: 0,0:01:54.26,0:01:58.89,Default,,0000,0000,0000,,responsible for testing your code, not\Nsomebody else. And the tools are highly Dialogue: 0,0:01:58.89,0:02:03.82,Default,,0000,0000,0000,,[inaudible] so unlike that, that statement\Nthat was done before. And so what the Dialogue: 0,0:02:03.82,0:02:08.44,Default,,0000,0000,0000,,argument here in the [inaudible] the\Nactual manifesto is that if with a good Dialogue: 0,0:02:08.44,0:02:13.49,Default,,0000,0000,0000,,process we'll get soft quality rather than\Nthere's a specific group that's supposed Dialogue: 0,0:02:13.49,0:02:20.14,Default,,0000,0000,0000,,to insure it that they're gonna beat you\Nup if you don't have it. So. Bdd and TDD Dialogue: 0,0:02:20.14,0:02:25.64,Default,,0000,0000,0000,,was I said earlier. The phrase behavior\Ndriven design was inspired by some people Dialogue: 0,0:02:25.64,0:02:30.86,Default,,0000,0000,0000,,getting confused about test driven\Ndevelopment. Here we're testing acceptance Dialogue: 0,0:02:30.86,0:02:36.29,Default,,0000,0000,0000,,tests, integration tests, and trying to\Ncapture the behavior. Tdd is gonna be step Dialogue: 0,0:02:36.29,0:02:41.85,Default,,0000,0000,0000,,definitions and actually write unit tests\Nand function tests, before you write the Dialogue: 0,0:02:41.85,0:02:47.21,Default,,0000,0000,0000,,code. So that's the. So the good news is,\Nyou're always gonna have the test up to Dialogue: 0,0:02:47.21,0:02:52.48,Default,,0000,0000,0000,,date because you're writing the code or\Neven before it. So here's how they work Dialogue: 0,0:02:52.48,0:02:56.99,Default,,0000,0000,0000,,together. Cucumbers describe the\N[inaudible]. You, you start off writing Dialogue: 0,0:02:56.99,0:03:01.56,Default,,0000,0000,0000,,the stories you want. They fail. Then it\Ninvokes the implementations, the Dialogue: 0,0:03:01.56,0:03:06.26,Default,,0000,0000,0000,,[inaudible] test. If it fails, you then,\Nyou implement the methods that are Dialogue: 0,0:03:06.26,0:03:10.90,Default,,0000,0000,0000,,missing. And then when it passes the\N[inaudible] test, you keep iterating Dialogue: 0,0:03:10.90,0:03:15.99,Default,,0000,0000,0000,,internally until you pass the [inaudible].\NAnd then once you've implemented the Dialogue: 0,0:03:15.99,0:03:20.95,Default,,0000,0000,0000,,feature properly, it, it will pass the\Ncucumber green step and you go back and Dialogue: 0,0:03:20.95,0:03:23.20,Default,,0000,0000,0000,,keep going through the development.