The 3 Types of Unit Test in TDD

Test Driven Development (TDD) and Unit Testing aren't necessarily the same thing, but they both produce unit tests. In either case there are only really three unit test types.

In this episode, Dave Farley, author of "Continuous Delivery" and "Modern Software Engineering" explores some of the nuts and bolts of TDD and how to put it to use in your software engineering approach. This TDD tutorial explores the three types of test with some simple examples to demonstrate each one. It then goes on to explore the difference between stubs, fakes, spies and mocks in testing and describe some common difficulties that people sometimes face.

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

🖇 LINKS:

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

📚 BOOKS:

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

NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.

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

🚨 MY TDD COURSE AVAILABLE NOW! 🚨

Learn to write great tests, and how to use those tests to improve the design of your software: with step-by-step guidance and demos by Dave Farley, and practical exercises for you to learn TDD and BDD.

Get a FREE "TDD Top Tips" guide by Dave Farley when you join our 📧 CD MAIL LIST 📧

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

CHANNEL SPONSORS:

[LE]

For those who are concerned the video starts at 8:40. The rest is Dave's usual effusive surrounding. Oh and thx Dave for the vid.

[richdobbs]

For me, the barriers that I faced with TDD have been my co-workers. Easy to figure out what tests to write as I drive development - impossible to convey that practice to others. Challenges to get code past code-reviews in a timely enough fashion to make rapid progress. Clueless managers that just didn't get the churning out of tests and code that results in predictable progress, couldn't differentiate it from unstable progress from cow-boys that delivered untested code that delivered surprises, that rewarded those heroic efforts that periodically saved the inherently chaotic situation.

One thing that really made TDD (or rather BDD) click for me, was the concept of programming by wishful thinking (which I think is the same as programming by intention). This technique has massively improved my ability to write simple and loosely coupled code. I think this is a topic you could cover quite well, maybe even with a small workshop video to go along with it 🙂

[TheXBaca]

Michael C. Feathers book on working with legacy code helped me tremendously. Not only in working with legacy code, but in getting stuff into a test harness. The legacy system i am working on is now under "test" and constantly refactored . The tests guided us to that. They made us realize a lot of flaws. TDD and Unit Tests are "simple", but they change a lot of things for the better. I will never again do without unit tests, the feeling of safety and feedback is to nice. I am still writing bad tests from time to time, but they become better as they allow easier refactoring and redesign of the code under test.
I wish i realized that earlier. And now i am more and more using TDD, its makes so much more fun, because of the instant feedback :). Your video motivated me to keep using TDD.

[benjaminludwig]

I've been looking for explanatory videos for a couple of days now and find that you have the best way of explaining things in a simple and consice, yet professional and challenging way so far. Thank you!

[jonathanaspeling]

So far my biggest barrier to practicing TDD has just been to set up my local dev env to be able to run with the cycle of TDD. Getting closer each day though and leaning a lot. Great content! Appreciate it 💪

[geekboy]

Refreshing! I've seen coworkers advocate for several of the anti-patterns you mentioned, glad to know I'm not the only one who thinks they're anti-patterns.

[rafazak]

Thank you for all of your outstanding content! One small thing. Please make the font of your code examples bigger. This would be a great favor for people watching your videos on the phones, like me. Again, great material like all the previous ones 🙏

[laketuna]

This channel deserves way more views. Way better than most of the channels out there.

[CosasCotidianas]

This video arrived to my feed in the precise moment. Thanks Dave. And happy holidays!

[queenstownswords]

Hello. I agree with you on the points you make in the video. I have noticed newer developers get caught up on the complexity of the unit test. The rule of 'no loops' in a unit test is a good one.

[urbaniv]

Great as always
Because of your videos I started with TDD and can't imagine how I ever wrote code in a different way...

[simonolofsson]

I’m so glad I found your channel. Thank you for all the great content!

[underdog]

Great material, really liked the summation, TDD implemented well will shout at us when we are doing something wrong, we just need to listen to what it is saying to us

[FlaviusAspra]

Unit tests are made hard by one major thing: not having the entire domain model in a completely independent component.

In the domain model, introduce pure fabrications (example `interface AccountRepository`) to achieve dependency inversion.

Then only test the domain model through the boundary, all in memory. These are called unit tests. They have the advantage that you're not bound to the implementation details of the domain, you just feed it data and check what you get back (from the return value, or via a test double).

I make only an exception for the "unit test at the boundary rule": when testing more convoluted algorithms.

Other than that, do a couple of sanity integration tests and the like.

[martinrohwedder]

Fantastic Video. I really got some good input of how I should approach TDD in my own projects :)

[drcl]

tried watching this a month or 2 back and had no idea what you were talking about. Spent time actually trying to do TDD like uncle Bob instructs and now its all much clearer. TDD can not be done backwards. You cannot write tests after without an incredible amount of pain.

[troythompson]

TDD clicked for me when I started writing them consistently. Once I caught my first bug in the pipeline from a unit test break, I was hooked. Now my test suite is mature and secure.

[marcusradell]

Best video I've seen with you so far, and the rest are really good too! The graphics makes the content simpler to digest (just try to keep the font size mobile-friendly if possible), and I love the playful animations!

The common mistake of adding tests that don't add new behavior was a great highlight, and I will probably reference this video a lot because of it.

Thank you!

[sachinkainth]

Great video. Love to see you do a live TDD session so that we can see exactly how it is done correctly.