"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.
"I connect with the way that you explain things. I can program procedurally and am trying to break out of that, but it's really, really hard. Most of the tutorials I look at don't help, because many don't understand there's a mindset shift. Your course helped move me closer." —Becca Williams
"We have started doing Learning Fridays, where we watch videos and than discuss. So far it’s been just the developers, and we’ve been focussing on programming skills. We’ve watched Series 2 of WBITDD and a number of Gary Bernhardt’s Destroy all Software videos. This has been an incredibly rewarding practice. We’re all getting closer to being on the same page regarding testing techniques. In just a few weeks, without making any other kind of definite process change, it has begun to really pay off in our codebase. Honestly, I think this practice is up there with retrospectives in terms of value to the team, and I would highly recommend it to others."
Series 1 and 2 are available as a free preview. Please start with the first lecture in Series 1 and you will be able to continue through the end of Series 2 before purchasing the course. It's my gift to you!
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
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 as The Code Whisperer, 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.
"Paralysis by analysis has been a real problem for me with finding the right way to organize code. Becoming comfortable with refactoring is already showing signs of liberation. I feel free to explore ideas as I learn to refactor with small steps that don't change behavior (with confirmation of tests). I want more of this. — J. W.
"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.
"I really enjoyed the TDD course, especially the way you conveyed the struggle of dealing with the unknowns of real problems. When I watched some [other] TDD videos a few years back, I used to come away with the impression that everything should be easy if you just follow the rules. If only the world worked like that!" — G. B., happy client of both online training and on-site consulting
PreviewBefore You Begin... (30:43)
PreviewAn Uncommonly Important Message
PreviewJust Before We Get Going... How to Write a Test List (7:52)
PreviewAdd Fractions in Java Part 1 (26:49)
PreviewAdd Fractions in Java Part 2 (21:53)
PreviewAdd Fractions in Java Part 3 (22:00)
PreviewAdd Fractions in Java Part 4 (23:12)
PreviewAdd Fractions in Java Part 5 (23:39)
PreviewIntroducing the Point of Sale Exercise (15:35)
PreviewSell One Item Part 1 (27:01)
PreviewSell One Item Part 2 (16:49)
PreviewSell One Item Part 3 (24:28)
PreviewSell One Item Part 4 (26:03)
PreviewBonus: Clean Up Those Nasty Junk Drawers
StartFirst We BDD, So We Can TDD (23:00)
StartMuch Ado to Sell Nothing (20:03)
StartHaven't We Been Here Before? (24:30)
StartFatal (Primitive) Obsession (30:31)
StartGetting Back on Track (21:36)
StartWhat Were We Trying To Do Again? (32:00)
StartFinally Selling Multiple Items! (26:04)
StartThe Thrilling Conclusion! (20:14)
Frequently Asked Questions
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."
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!
Ask them in the comment threads on each lecture page. I invite you to offer answers to your fellow learners, too!
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’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):
- Make TDD steps as little as possible;
- Remember that I am a human and I am allowed to make mistakes (and learn something out of them);
- 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
@jbrains congratulations on the #WBITTDD courses. Worth every penny, lots of little nuggets in every episode.
— Steve Tooke (@tooky) April 24, 2015
" 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
Imprescindible,The World's Best Intro to TDD http://t.co/5pq0qY49EL @jbrains #tdd #development
— Julio Muñoz Gallarín (@pretonik) March 27, 2015
"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
Does your company require a purchase order or invoice before paying? We can help with that. Contact us and we'll work out the details.
Worried about VAT? Don't worry: you can use your company's VAT ID at checkout so that you don't have to recover VAT.
Are you unsure about something else before you purchase? Visit here to ask your question!