TDD By Example Kent Beck

English In this video we are going to talk about the book and actually this entire section Test-Driven Development by Example. It's going to be highly influenced by a book by Kent Beck. Now this book originally published back in 2002. Kent Beck has produced this rather iconic book on testing software. This is kind of what helped establish test-driven development as a modern best practice and even though it was published back in 2002 I'm recording this video in September 2018. Sixteen years later Amazon is listing it at number 17 in testing and then number 33 in software design and engineering. So you can see even though it's such an old book by development standards, it's still very popular. I've read the book. It's got a lot of great material in it. Like I said right now in the industry we kind of just assume that test-driven development is the way to go. Very few people dispute that. But we need to step down memory lane a little bit. Back in the early 2000s, people would need had to be sold on test-driven development. It was something that was evolving. People are starting to accept it. People were pushing back on it so it was a little more controversial back then and that this book really helped drive it to the forefront of the software development community. Now Kent Beck very well-known he was one of the original 17 people that signed the Agile Manifesto. Originally was known as the founder of SUnit back in the SmallTalk days. SmallTalk was like the big OO language prior to Java. SmallTalk so SUnit was the precursor to JUnit. Of course I've mentioned before that Kent Beck is one of the people who founded JUnit which we'll be looking at a lot in this course. Kent also helped found the extreme programming movement. So this was big a few years ago. A number of good practices came out of that and that's very very intertwined with the agile stuff. I'm not gonna focus on all those practices here. I'm really kind of focusing on the testing aspects of that. I'm talking about Kent because he's really considered a leading advocate for tester and development. Kent is also known as a well speaker a keynote speaker on a lot of technical conferences. I think he spent about seven years on Facebook. This is a great quote from him. I'm not a great programmer. I'm just a good programmer with great habits. It you really makes you think about that one and that is very important as a software developer is to have good habits. So good habits will lead you to quality. I've got a couple other popular quotes here from him. If I have the same logic in two places I work with the design to understand how I can only have one copy. Designs without duplication tend to be easy to change. This is a very important concept. I see this violated a lot were you repeat code and logic and values in different places and this can really get you in trouble fast especially on a larger system where you replicate it. Let's say you do the same thing. One changes, one doesn't and then you cache it. Which one's right? So a very very bad thing. Another one here is don't make more versions of your source code rather than add more code bases. Fix the underlining design problem that is preventing you from running a single codebase. I have seen this violated multiple times especially in shops with less experience. People that built literally make a version of it. I've seen different libraries and classes where a little cut and paste into another package and then make a small few small changes and it literally will lead you down the road to spaghetti code and something that is just a nightmare to maintain. Another thought about is if there are forms of testing like stress and load testing that find defects after development is in quotes complete, bring them into the development lifecycle. Run load and stress tests continuously and automatically. This is a good point as your system grows. I see a lot of people try to optimize too early especially junior people that they'll try to get that little bit of performance out of the system way early in the process. There's always time for that. Premature optimization can cost a lot of time. Having load and stress tests to load up the system that will show you where problems are further down the road. So that's why I included that test just my own experiences where let's hold off a second. Let's not try to optimize every last cycle out of something that's going to run once a day. Your time as a developer can be spent in a lot other places that will bring a lot more benefit. Now in this section of the course. Think of well establish a tester and development is widely considered a best practice. Now what I want you to see is test-driven development in action. What we're going to do is start with a very simple example with tests of course and then we're gonna see how to evolve this example. We're gonna basically start with getting it to compile, very simple concept of compile, and we will know that it will not be complete. It's going to be ugly. It is not going to be quality. We are going to then use a TDD approach to evolve it to clean quality code. so this is something that we're going to evolve and change and we're gonna see how that changes work. Now the reason I've been talking about Kent in the book. We are going to use the money example and this is used in the first section of Kent's book, Test-Driven Development in Action. This is right out of there. I'm not being shame about it. The money example has been used numerous times to help teach and see how test-driven development works. The money example actually comes back from Kent's SmallTalk days and he got the example from Ward Cunningham who's interestingly enough at the founder of the Wiki. Ward's actually a really interesting guy but he's a blowout site to scope with this course. But just to let you know where that is from. In this example we are gonna start with a really simple example like I said before and it's not even going to be able to compile initially and we will evolve it to work and compile. We are not going to be following commonly accepted practices. But we are going to evolve our code to quality code and we're gonna use a test-driven development approach to it. Now the approach I'm gonna use. I'm going to be mirroring the first part of Kent's test-driven development by example book. You do not need the book for this course. I do however recommend reading that book. If you have access to Amazon, I think I have a link to the book and the readme of the github repository. But like I said, you don't need the book. I'm gonna be summarizing each chapter we're gonna go through. There's about a dozen chapters that show you this example. They're pretty simple but the important part is to show the technique and like I said that the book was written in 2002. I think it's like it's going from memory that's like Java 3 or Java 4 days. So very early stuff. Very early version of JUnit so it's kind of a trip down memory lane. I'm gonna be using at least Java 8 and the latest release of JUnit 5. I'm gonna show you how to set that up and run through this course. So I'm gonna take what's in that book and update it from 2002 to 2018. We're gonna have a lot of fun with this and see exactly how to apply test-driven development.