A common issue programmers have when they try to test real-world software is how to deal with third-party dependencies. Let’s examine an old, bu

Don’t Mock What You Don’t Own in 5 Minutes

submited by

Style Pass

2022-06-21 23:00:07

A common issue programmers have when they try to test real-world software is how to deal with third-party dependencies. Let’s examine an old, but counter-intuitive principle.

Once upon a time, I made a stupid joke on Twitter about London School of TDD’s1 Don’t Mock What You Don’t Own principle:

While it didn’t get me fired, it led to me being tricked into giving a 5 minute-long talk2 about it. Given the confused replies I got to the joke Tweet, I’ve decided it’s worth writing down the contents of the talk for posterity.

Disclaimer: I don’t like mocks in the original sense: a test object, that mimics another (usually complex) object, records calls to its APIs, and allows you to make assertions over those calls.

However, this principle is still useful, because it applies equally to any other type of test object (if you’re confused by the differences between mocks, fakes, stubs, et cetera, I recommend Martin Fowler’s Mocks Aren’t Stubs). I will keep using the term mock throughout this article to remain congruent with the name of the principle and I will be using a popular mocking library in my examples for familiarity, but you don’t have to tell me why you don’t like mocks.