Hacker News Reader

Comment by kstenerud | Hacker News Reader

So... mock the storage? This very quickly becomes a slippery slope.

Fake, don't mock. Write, or ask the team that provide the external dependency to write, a small piece of code that behaves like your external dependency, but in-process. You'll thank me after about the 47th time you're guessing (inconsistently, possibly incorrectly, and definitely overly verbose) how the external dependency actually works. Ban mocking libraries.

Isn't that effectively the same thing? The fake implementation needs to mimic the API your software expects to run against, and must give valid-seeming results and also keep up with development of that external program for the variety of tests you'll run against it (which will grow, increasing the complexity of the fake). You'll of course have to do this yourself, because your vendor isn't going to do it for you. So now you have two problems.

Fakes are not mocks. The fake is just another module. Assuming no updates, it is written once. Mocks are written 47 times, inconsistently, while focusing primarily on other tasks. If there are updates needed, better to fix them in one place than chasing 47 test code locations with inconsistent usages.

Furthermore, these are external dependencies that can't be run in-process. If a dependency can be run in-process (aka library), there is no justification to ever mock it. I've even seen codebases that mock their own class B in order to test class A. Run the production code already. Ban mocking libraries.

Testing against external dependencies is only one form of testing.

Unit testing with mocks is another form. One does not replace the other.

Agreed. Using mocks while testing vanilla in-process code is never justified.

Reply on news.ycombinator.com