X7d1lx5rjqck5vz1xoe0 worlds best intro to tdd salmon

The World's Best Intro to TDD, Level 1: TDD Done Right

How should you practise TDD... really?

   Watch Promo Let's Go!
"Generally speaking, I like your material best of all the TDD material I've gone through (including Uncle Bob, Industrial Logic, Plural Sight)." —S.L.

Would you like to take the first two sections of this course right now, to see how much you're going to like the rest? You got it! For you, my friend, free. (No tricks. Just look for the little buttons marked "Preview".)

JBrains is very scientific in how he practises software development, and this is demonstrated throughout the course. This skill is one I want to develop very much. I also learned about new ways of working, namely, the ‘Pomodoro Technique’ and ‘Getting Things Done’, which have made me much more productive.—Hemal Varambhia

Your Instructor


J. B. Rainsberger
J. B. Rainsberger

J. B. (Joe) Rainsberger is one of the "second wave" of TDD practitioners: he learned directly from the pioneers of the field. His book, JUnit Recipes, was the standard for over a decade for Java programmers who wanted to do what we today call developer testing or programmer testing. He has taught thousands of programmers around the world to bring high discipline to their work for well over a decade.

Not "just a programmer", J. B. has taught people how to manage the never-ending onslaught of work, figure out how to adopt new working practices chaos-free, understand and even grow to respect their most annoying co-workers, find the time and energy to improve as though finding loose change in the couch cushions, turn their dreary day job into a Dream Job–even how he enjoyed his first retirement from age 34 to 40! Software, life. Agile, not Agile. He's up for anything.

Read his work at jbrains.ca and blog.thecodewhisperer.com, and don't forget to sign up at sign-up.jbrains.ca—subscribers there got to sample this training material and received discounts on this training course. Don't miss J. B.'s next launch!


How should you practise TDD (test-driven development) really?

The rules of TDD are dead simple: write a test, make it pass, improve the design. Anyone can do that. Unfortunately, most people just aren't getting the results from TDD that they expect. This stops a lot of people from trying and causes still more to give up just when they're about to turn the corner—and therein lies your advantage. If you learned how to do TDD well...

  • You'd stand out at work as the go-to person. They'd respect you. They'd rely on you. And they'd have to pay you. (Let's not be coy about that. I left my job at IBM because they couldn't pay me any more money without making me a manager, and 27-year-old me would have made a terrible manager!)
  • You'd get to walk out of the office with all your work under control while your colleagues scrambled to fix the three bugs they'd introduced that morning. (I remember scrambling. I also remember sleeping like a baby. I preferred the sleeping like a baby.)
  • When you said, "It'll take a week", it'd take a week! Not like Bill who's been saying he's 90% done for the last three weeks. (Legacy code gets in the way, but if your task estimates for legacy code work were even close, you'd be a hero.)

There's more, but that's not bad, is it?

The bottom line is this: a lot of programmers have built lucrative careers by practising TDD. Some have done it by teaching others to do it. Some have done it by building high-quality products at high speed and maintaining that speed long enough to outlast their competition. Some have done it by becoming the expert within their company, who works on all the interesting stuff, has the credibility to choose what they want to work on, and either earns more or works with less stress—and often both!

Now wait a moment... I'm not trying to tell you that TDD gets you there. I'm certainly not trying to tell you that TDD is the only thing to get you there, or even the best thing to get you there. I'm only telling you that TDD helps a lot of people get there. Even better, lots of people just don't get TDD, so if you do, then you have a fantastic chance to catch up to them, blow past them, and leave them in your wake.

This course teaches you how to do TDD and how to get it. How to really understand it. How to do it well and quickly—and how you can use that to become a top-notch, sought-after, highly-paid programmer. (A lot of the nuggets of wisdom in this course go beyond TDD and touch on other habits of successful programmers.)

By the time you finish this course, you'll know—and be developing—habits that will turn you into a good programmer, then a great programmer, then maybe even an awesome programmer. (Really, you'll make yourself good, great, then awesome. I'll simply show you habits that'll help you stay out of your own way and get there sooner.)

I used TDD as a deep practice approach to really understanding how to design software well. I didn't even realize that that's what I was doing! That's how powerful deep practice is in building skill, and TDD sped me along that road in a way that reading books, drawing diagrams, and programming in a trance several hours per day could never do.

Level 1 will give you an unbeatable foundation and it'll start from the very beginning. If you don't know anything about TDD, you can start here. Even if you think you know TDD, you might never have seen it practised this way before. You'll learn at least all this:

  • How to do TDD (duh!): red, green, refactor.
  • What makes designs stand the test of time, why this matters, and the four simple rules that help you figure out the rest.
  • The critical importance of writing small, fast tests, and how to do it.
  • The number one mistake that other programmers make—unhealthy dependencies—and how writing the test first makes it easy to avoid that trap.
  • Testable code tends to be easier to maintain, as you'll experience over and over again.
  • Avoid the typical traps that other programmers fall into when they practise TDD: slow tests, runaway mock objects, insanely tight coupling, and endless "refactoring".

Where others fail with TDD, this course will help you succeed.

This course is perfect for programmers in any modern programming language, and even a few archaic ones.


"I've found the series invaluable. Although the the example is simple, there is so much great information. I find my self rewinding to make notes, highlight key phrases, and it helps me reflect on my current practices. It's always good to return to the fundamentals." —N.H.

Class Curriculum



Looking for the new Enterprise Plan for a better company-wide rollout of TDD training? You'll find it at the bottom of this page.

Frequently Asked Questions


When does the course start and finish?
The course starts now and never ends! It is a completely self-paced online course–you decide when you start and when you finish.
What if I am unhappy with the course?
We would never want you to be unhappy! If you are unsatisfied with your purchase, contact us in the first 30 days and we will give you a full refund.
What do I get in this course?

There are almost 20 hours of video demonstrations showing both the Classicist and Mockist approaches to designing the first couple of features of an application that integrates real-life hardware devices.

You also have an opportunity to discuss the course with your peer learners, and since each discussion thread relates to an individual video, you never have to worry about spoilers!

This course also includes a coupon code for one FREE month of The jbrains Experience, an interactive course where you learn directly from and with J. B. by asking and answering questions.

What if I have questions about the videos?

Ask them in the comment threads on each lecture page. Feel free to offer answers to your fellow learners.

What's the technology stack?

For this course, plain Java 8 on IntelliJ IDEA 14. Programmers on other platforms have told me that the concepts shine through, even if they're not seeing demos in their favorite programming language.

I'm not a Java programmer, so this isn't for me, then, is it?

On the contrary, although I demonstrate the principles in Java, you can follow along in any imperative programming language: procedural, object-oriented, or functional. I suppose a Prolog programmer wouldn't find it as useful.

One student who works in C# told me, "I have just finished Series 1, and definitely a .NET developer would learn a lot from it. What specifically struck me most is the practice of writing a Test List, and doing microsteps when applying TDD."

I’ve recently been able to put (Contract Tests) into practice at my day job. And having that contract test was great! It immediately showed me how my assumptions did not match those of the internal service I was using. —Ben Davis

They love this course!

"The best thing it did for me is that it showed a more complete picture and took away the guilt of not having perfect habits." -T.D.

"I reached an 'Aha' moment when I was flailing [...] I ran before I could walk. I stepped back and realised I needed to (take a smaller step) [...] This was an interesting observation. After (that), the process continued smoothly." —Hemal Varambhia, referring to Series 1.

"I thought the methodical process was extremely interesting to watch. I am new to TDD and these videos have been a big help!" —Jacob Chae

"The pacing was great. I've been doing TDD for awhile, but I found it nice to be able to see best practices and to see your thought processes as you present the examples. Hearing how you think is very valuable to me." —Jim Strawn

"It reminded me of something that always stuck out for me reading some of Ron Jeffries' TDD writing (maybe C# adventures?). He would call out when he thought he was taking a big step, and why—but then do it anyway. Safe in the knowledge he could step back and go slow again if his hunch was wrong. That awareness of what you're doing, is a really important part of the discipline." —Steve Tooke

"[It felt like] I was pairing with you." —Anonymous student

"I mildly disliked having to wait for each video [...] just because I was eager for more at the end of each." —Jonathan Mendez

"I realized I had forgotten all the little steps (like adding instead of changing) and that that has often gotten me into trouble resulting in large reverts and hours wasted." —Daniel Sandberg

"Absolutely fantastic. Used the videos to teach TDD to my husband who is just starting to learn about it. Personally, after practicing it for 10+ years now, it was a great refresher course!" —Supriya Joshi

"I have just finished Series 1, and definitely a .NET developer would learn a lot from it. What specifically struck me most is the practice of writing a Test List, and doing microsteps when applying TDD." —Joey Samonte

"Been doing TDD for a while, but this was a good re-introduction to the micro steps I sometimes manage to forget." —Patrik

"It helped me remember three fundamental things, which often times I forgot (and feel bad about it):

  1. Make TDD steps as little as possible;
  2. Remember that I am a human and I am allowed to make mistakes (and learn something out of them);
  3. There isn't one single way to do things (TDD in particular);

In addition, videos were concise and they went straight to the point." —Antonio Scandurra

"I was impressed by the meticulous planning in the first video, so much so that it might not appear that way to those who haven't practiced TDD for a long time. [...] Seeing such a competent elucidation gave me the happies." —Amitai Schlair

"You are honest about your mistakes. This makes you more 'human' as many people tend to see 'famous' coders like you as kind of 'godlike'." —Anonymous student

"I liked hearing your thought process. I liked that you differentiated between what you thought was important and what you would be willing to defer to a pair's judgment." —Jonathan Mendez

"I liked the demonstration of how small the steps can be. And the frequent commits. And your explanations of some of the distinctions you're attending to as you choose tests and write code." —Dale Emery

"I like the velocity of the exercise and the tone. I was never bored waiting for you to advance. I like the style: write a little, explain something, reasoning about why I'm doing this in his way... " —José Carlos Gil

"I like your explanations of what you're doing and WHY. I liked seeing micro-committing, writing tests backwards, and separating tests by behaviour. Also liked that you can admit you make mistakes. Thanks!" —Let's Developer

"It was a well chosen example executed very thoroughly. Even though I had experience in TDD, I learned something new. Like the add new assert before removing old assert trick." —Gregor Riegler

" I've always liked the way how you are able to explain things and again in the videos you did a great job explaining each step. I especially liked the fact, that you came up with a list of tests before writing some code. I usually see guys immediately start coding and coming up with the test cases while they code. So often important test cases will be forgotten by the devs." —Claus Polanka

"Clear examples. Practical advice." —Sebastian Larsson

"It's a good example in order to see a pattern emerge and how to move responsibilities towards appropriate places only improving naming." —Anonymous student

"Good pace, really clear explanations of what you're thinking as you do it." —Matt Parker

"I liked the pace, and the focus on discipline." —Steve Tooke

"Easy to understand example well explained." —Gavin Stewart

Get started now!