A small-scale rule of thumb. This article will land much better with a concrete example, but I am drawing a blank here, so you gotta just blindly trust my say so!
I work in silicon verification where we do extremely thorough testing, and that is nonsense. It’s perfectly fine to test internals of a system because often it is difficult or impossible to get good test coverage of internal parts of a system just using the public interface.
Unit and method tests are still useful to quickly find where the issue occured. If you just test the input and output of the program, no its individual units, then in an error case you still need to figure out where it exactly went wrong. So in short, its not just to check if program behaves correctly, unit tests also helps debugging.
There is also this gem in the post:
I totally agree! With containers you might not even have to mock your IO but can check if the application behaves correctly.
One is to prevent user abuse the other is to prevent coder abuse.
I work in silicon verification where we do extremely thorough testing, and that is nonsense. It’s perfectly fine to test internals of a system because often it is difficult or impossible to get good test coverage of internal parts of a system just using the public interface.
Unit and method tests are still useful to quickly find where the issue occured. If you just test the input and output of the program, no its individual units, then in an error case you still need to figure out where it exactly went wrong. So in short, its not just to check if program behaves correctly, unit tests also helps debugging.