Test Driven Development Tutorial For Beginners

What is TDD, what does it take to get started learning to do it, and how should you practice it? This Test Driven Development tutorial explores all of these ideas in the context of a demonstration of working on a simple Coding Kata, called FizzBuzz. It also demonstrates the best place for to start, TDD for beginners, if you want to get started.

In this episode Dave Farley of Continuous Delivery demonstrates the easiest way to begin with TDD and how it morphs into Test Driven Design, using the excellent practice tool Cyber Dojo. Cyber Dojo allows you to practice TDD in a wide variety of languages and technologies with almost zero setup. Dave demonstrates the use of Cyber-Dojo at the same time as describing some subtle and important aspects of basic TDD.

-------------------------------------------------------------------------------------

LINKS 🔗

-------------------------------------------------------------------------------------

📚 BOOKS:

📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
(Paperback version available soon)
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.

📖 "Continuous Delivery Pipelines" by Dave Farley

📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble

-------------------------------------------------------------------------------------
Also from Dave:

to get regular updates, advice and offers from Dave and Continuous Delivery!

-------------------------------------------------------------------------------------

CHANNEL SPONSORS:

[Soliber]

This is going straight to the dev chat channel of my team 😄

[arakovskiy]

I see here a comment that tdd is slower than regular development. It's demo, guys!
IRL Tdd is much faster than anything else since you don't spend almost any time on fixing stupid mistakes. Actually I hardly ever use a debugger because there's no need.
It is also faster since you don't make your solution too complicated to write, test and maintain.
You even don't spend time on trying to sort out what is happening in your own code because it's always refactored to the best design you could imagine at the moment.
And if you think that your old design sucks - go on and refactor it. Everything is covered so it's 100% safe to refactor.

[Wisaalmusic]

This was wonderful! In answer to your question at the end, yes please to publishing the second half of the video, if you see fit.

[kikitauer]

I am a baby developer (just started 3 months ago) but I naturally started doing exactly this. I think it is great not only for catching early errors and mistakes but it also deepens the joy of creating a functional code because you get the feedback so frequently.

[Mozartenhimer]

I'm trying to sell TDD as Specification driven development, as if you can agree what a program should be outputting and the api, the work to be done is extremely clear cut. Would like to see more of this type of content as well!

[arakovskiy]

God, that bookshelf! All legendary books together!

[itsmeben]

Mr. Farley, this is amazing. I usually listen to you for your theoretical content, but I wanted to practice TDD so that I can start following it. I sat down to start and I couldn't figure out what my first test should be so I did a YouTube search.

I just followed along on my own in cyber-dojo and now I'm moving on to part 2. This is great, practical content. Thanks for everything you do!

[foxmark]

Many years ago I have been told to ba lazy as a developer and return as soon as possible. I agree you create multiple exit points but your code is getting 'flat' (no/less nested ifs). Keeping in mind that 10line function can be considered long - it should be safe to say that code should be easy to read anyway. As always a pleasure to learn - thank you for sharing your knowledge.

[julianbrown]

As a big advocate and teacher of TDD, and an interviewer of candidate engineers for my teams it always amazes me just how many people claim to do TDD but don't actually have a clue. Even then the difference between good (useful) TDD and poor (fragile) TDD is a big gap. Once the penny drops it is normally plain sailing and any tool that supports that good behaviour has to be a worthy addition to the toolbox to get everyone across the line in a shorter time scale. Doing all of this in practice tends to be the big bugbear though, where TDD skills blend with unit testing and people go back to old, bad habits just to get work done rather than follow the path and make sure the code output is built the right way

[zrjmldl]

I would love to see more tutorials like this or courses where you build a full project with TDD!

[alessandroferrari]

would love to see more of these hands-on videos, Dave! Thank you for all your inspiring work!

[solaaar]

That's the kind of videos i love, it very instructive to have tutorials of such advanced topics from someone as experienced as you. because all the tutorials nowadays focus on technologies and tools rather than software engineering best practices.

[fabianogomes]

Saving to watch later. This video goes to my "must see" playlist.

[RadoMich]

"Experience is a hard teacher because she gives the test first, the lesson afterwards." – Vern Law 😁

[mCoding]

Great advice! I would have liked so see a bit more about the transition in the code going from simple cases to the general answer. Following the absolutely simplest approach that you mention, we test 2, then 3, then 5, then maybe 15, and at that point we have an implementation that is effectively a lookup table of the correct answer for our test cases. Each time we add a new test it seems that the simplest thing to do is to add another if check that just outputs the correct answer for that specific test case, which brings us no closer to actually solving the problem. I'd love to hear your perspective on when/where/how we transform a lookup table of answers into a solution that works for a general input. Is this the purpose of the "refactor" stage you mention?

[sdb]

It's pay now or pay later. I admit I've never done this at it's purest form, however once I had the opportunity for a client BA giving us the inputs and outputs for a particular system and while he was doing this I thought to myself that I could finally do some TDD. It went great! There were 2 glitches found: The first was a scenario that the BA left out and the second was when a developer wrapped my code and did not do TDD on his wrapper. (i.e. my code behaved as expected!)

[brattonross]

Loved the practical example, great video. I just started reading Kent Beck's TDD By Example book a couple of nights ago, so this has helped remind me of some of the principals. Cheers!

[seanlennon]

I encountered this site about six years ago as part of a job interview process, wonderful site.

[MrAbrazildo]

Good. But what I want to see is tests when you must read/write variables that are not passed as arguments to the f().
19:46, I'm against that. If the code is holding a variable to exit later, in a later reading you won't know in advance what will be made of that variable. After a whole reading, loosing time, you will eventually realize that the code should just exit right away.

[jonmoore]

Thanks for this nice introduction to TDD and making me aware of cyber-dojo, a great resource! As a TDD noob one question is should I create tests for input parameter validation ie checking the values passed to my code are in the correct range etc? If this shouldn't be tested as part of TDD where, if anywhere, should that be tested?