The 3 Types of Unit Test in TDD • Dave Farley • GOTO 2022

We’re so pleased to announce that we’ve teamed up with Dave Farley, author of “Continuous Delivery” and frequent GOTO Conferences speaker, for a monthly video series featuring ideas about continuous delivery, DevOps, test-driven development, BDD, software engineering and software development in general.
Find plenty more from Dave on his ‪@ContinuousDelivery‬ channel.
Dave Farley - Continuous Delivery & DevOps Pioneer, Award-winning Author, Founder & Director of Continuous Delivery Ltd.
ABSTRACT
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.
CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
bit.ly/DFTraining
RECOMMENDED BOOKS & LINKS
You can grab Dave Farley's new book 'Continuous Delivery Pipelines' here:
leanpub.com/cd...
David Farley • Modern Software Engineering • amzn.to/3GI468M
Dave Farley & Jez Humble • Continuous Delivery • amzn.to/3ocIHwd
Forsgren, Humble & Kim • Accelerate • amzn.to/367RI5o
/ gotocon
/ goto-
/ gotoconferences
#GOTOxDaveFarley #TDD #Programming #SoftwareArchitecture #CD #ContinuousIntegration #Testing #UnitTesting #UnitTest #DevOps #DaveFarley #GOTO #GOTOcon #ContinuousDelivery #Accelerate #Complexity
DAVE'S LINKS
www.continuous...
/ davefarley77
www.davefarley.net
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
www.youtube.co...

[@ilovepickles7427]

Brilliant vid. One of my favs. Will come back to this one over and over when I need a reminder.

[@Walruz1000]

What is your view on verifying interactions in tests, e.g method A was called twice with these parameters? Some people feel quite strongly that this tightly couples your test to your implementation, I have heard developers say that using mocks also tightly couples your tests to your implementation and they should be avoided as they can make refactoring difficult.

[@-taz-]

There are multiple reasons for your unit under test to call a function. Is it an implemention detail, or an outcome? If it's a function that concatenates strings, don't mock it or test it. Don't test impl. details. If it outputs some text, then it's an outcome/effect/behavior. Do what you must do to assert that it works. Good design means that you can find a concise and clear way to test it, hopefully not requiring a mock at all. For example, if you write to a stream, you can pass in a string stream in your test, while production might use a file or HTTP/socket stream.

[@ericpmoss]

Maybe this was implicit in what you said, but I don’t see much point in writing tests until you know your code is already headed in the direction you want. Just as customer requirements are vague or and/or changing, a lot of coding is exploring, and often that exploration changes our perception of the problem, including the interface we want, too.

[@-taz-]

If requirements are vauge, forget TDD. If you try to code it, you're probably wasting time building the wrong thing entirely. Use BDD. Pull in stakeholders and do an example mapping dicovery session. Then formulate, then develop acceptance tests for things with direct business value. When you're developing software toward that known goal, and you are the "user" or caller of that software, then TDD makes perfect sense. The failing test will let you decide how to call your software, what to pass in, and what to get as output or effects. There's not much point in writing code until you know at least that much, so TDD is effective.

[@familyshare3724]

1. Good tests 2. Bad tests 3. No tests

[@Bryft]

Great job, Dave! TDD needs demystifying, and such down to earth explanations, so people are eager to try it. But these code snippets look like someone gave Python to a Java person ;-]

[@-taz-]

The code snippts are all tests! They use the `unittest` library. You might prefer `pytest` which I think is more "Pythonic."

[@Bryft]

@@-taz- unittest is based on junit, so I agree, pytest seems more natural. But I think I also meant there the code which these tests are checking. If you have a class with a single public method you should have written a function instead. There's a great talk "Stop writing classes" by Jack Diederich on that topic ;-]

[@-taz-]

​@@Bryft Ok, then we are in vehement agreement here. :) I've been telling people that for decades, and even watched that exact video when it came out, and again around 3 years ago.

[@alvaromoe]

Captain?