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.
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.
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.
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.
I would add that human interfaces need to be tested by humans (preferably not your paying customers), machine interfaces by machines.
If the framework you're using allows for ui testing, you must use it.
For example in flutter, you can check whether a component is visible on the "screen" and simulate an action with it.
No need to ask a human to test the new ui if you can detect that the new button isn't visible on the "screen" .
Then once you know what's supposed to be there is there, a human must test it.
This is all good advice.
Hopefully AI has killed TDD dead dead dead.
TDD is one of the worst concepts ever concocted by the software industry right up there with UML.
It’s all very ThoughtWorks.
One of the very best things to come out of AI development is the extent to which it sends TDD to the ninth level of hell.
The best AI workflows works heavily with tests at the moment. Having tests up front means the Ai knows its failed, and attempts to fix it.