Hacker News Reader

Comment by viraptor | Hacker News Reader

It's nice that this reminder surfaces from time to time. Hopefully there are a few lucky 1/10000ths today.

I'd just add some nuance to:

> If you cannot reach the untested lines with the public interface of your software, maybe you can just delete those lines. Do not reach for stubs/mocks to achieve 100% test coverage, try to find a scenario of how to run through these branches by using the API from a realistic point of view.

Sometimes you need a few mocks for exceptional situations. You're not going to fill up your disk just to check that ENOSPC, or try to race the test with bringing down an interface to reproduce network timeouts.

View on HN

That is a valid point. This is exactly when you should use a mock.

Wouldn't it be easier to just create a small ISO file, mount it and just fill that up?

When your code uses inversion of control, which can allow your code to inject different versions of your dependencies, such as a mocked disk API, or network resource, the code is often more testable because of the separation of concerns, and thoughtful design.

I would answer your question by stating your alternative _might_ be an easier test to write now, but amortizing the (already low) cost of having a code written with first practices in mind will be much easier to work with in the long run. Including across small and large teams. Ultimately we want our code to be reliable and scalable, and we can do that by making our code testable and maintainable.

You can of course test the UI by just reporting the file system to be full, but when you want to test your low-level stuff you would be resorting to faking syscalls. That is of course doable, but why do that when you can just create the situation directly.

Possible, yes, but certainly not easier—especially not if the test harness doesn’t manage filesystems anywhere else.

And even then, that’s still a behavior mock, of a kind. There are lots of ways in which a dummy ISO mount behaves much unlike filesystems your deployed code might run on. You could address those issues, but doing so is very laborious and starts requiring more and more specialized code. Unless the code under test is part of a database storage engine or something, it’s likely even less worth it.

You'll need permissions to mount things. It may be restricted in CI environment, so I wouldn't rely on it.

Reply on news.ycombinator.com