A common issue when writing tests for real-world software is how to deal with third-party dependencies. Let’s examine an old, but counter-intuitive principle.
While I largely agree with the net result, I think this mantra kind of misses the point and could easily lead to dogmatic programming.
Mocking external tools is bad because it indicates poor code and testing structure. We want our tests to be predictable and indicate issues only if something directly related to the test changes behavior. If a bug is introduced, ideally only one or a small handful of tests will fail. If the network fails, ideally no tests fail. It’s all about limiting the ways your test could fail to just the thing you’re testing.
For example, if that client library expects an extra argument (maybe auth token), every function that uses that call could fail if it’s not mocked, whereas if it’s mocked, only the one or two tests that hit the API more completely would fail.
This leaves code untested, but that’s fine because it’ll be caught with integration testing. Unit testing tests units, and we want that units to be as small and independent as possible.
So it’s not about whether you own the code, it’s about being very clear about what it is you’re testing. Let’s say I have the following setup:
In this case, I’d mock b when testing a, mock c when testing b, and mock external_library when testing c. It has nothing to do with whether I own it, only whether I’m testing it. If I’m mocking external_library everywhere, that’s a code smell that my code is too tightly coupled to that external library. The same applies to b or c. It has nothing to do with whether mocking an external thing is good or bad, but whether I want that coupling in my code.
Well structured code doesn’t need this “rule,” and and poorly structured code should be caught before getting to the point of writing tests (unless you’re doing TDD, but that’s a dev strategy, not a testing strategy per se).
While I largely agree with the net result, I think this mantra kind of misses the point and could easily lead to dogmatic programming.
Mocking external tools is bad because it indicates poor code and testing structure. We want our tests to be predictable and indicate issues only if something directly related to the test changes behavior. If a bug is introduced, ideally only one or a small handful of tests will fail. If the network fails, ideally no tests fail. It’s all about limiting the ways your test could fail to just the thing you’re testing.
For example, if that client library expects an extra argument (maybe auth token), every function that uses that call could fail if it’s not mocked, whereas if it’s mocked, only the one or two tests that hit the API more completely would fail.
This leaves code untested, but that’s fine because it’ll be caught with integration testing. Unit testing tests units, and we want that units to be as small and independent as possible.
So it’s not about whether you own the code, it’s about being very clear about what it is you’re testing. Let’s say I have the following setup:
def a(): b() def b(): c() def c(): external_library()In this case, I’d mock b when testing a, mock c when testing b, and mock external_library when testing c. It has nothing to do with whether I own it, only whether I’m testing it. If I’m mocking external_library everywhere, that’s a code smell that my code is too tightly coupled to that external library. The same applies to b or c. It has nothing to do with whether mocking an external thing is good or bad, but whether I want that coupling in my code.
Well structured code doesn’t need this “rule,” and and poorly structured code should be caught before getting to the point of writing tests (unless you’re doing TDD, but that’s a dev strategy, not a testing strategy per se).