TDD By Example Kent Beck

A free video tutorial from John Thompson • 500,000+ Enrollments Worldwide
Spring Framework Guru - Best Selling Instructor
24 courses
364,880 students
Lecture description
Learn about the original author of JUnit, Kent Beck, and his passion for Test Driven Development.
Learn more from the full course
Testing Spring Boot: Beginner to Guru
Become an Expert Testing Java and Spring Boot Applications using JUnit 5, Mockito, Spring Boot, and More!
20:43:42 of on-demand video • Updated January 2025
Learn Important Concepts behind Test Driven Development
Understand different types of testing - Unit, Integration, Functional
Master the JUnit 5 Testing API
Easily integrate Mockito with JUnit 5 Tests
Migrate JUnit 4 tests to JUnit 5
Test Spring Framework Applications with JUnit 5 and Mockito
Write Unit Tests with Spring MVC Test
Learn to use testing features of Spring Boot
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.