In theory yes, in practice I mostly disagree. The ideal is to test everything, the public API and all the internals. But there are only so many hours in the day

In theory yes, in practice I mostly disagree. The ideal is to test everything, the public API and all the internals. But there are only so many hours in the day so if you have to choose (which most of us do) then the best place to put the majority of the testing effort is in the public API. The reality is that there will always be bugs...always. While 100% bug-free is a valiant goal, it is pretty much impossible to achieve in a complex system. However what is achievable (or more achievable at least) is being almost completely bug-free at the public API level. From a business point of view, this is the only thing that really matters because it is the only thing your users and customers care about. In your fruit basket example, there are two fixes for this. Either improve the public API tests to verify that an hour later the file is still there. Or you use a storage technology where you can assume it will work correctly (Postgres, S3, etc) and then have a code review. There is definitely an exception to "only need to test the public API". That is when a very complex component has to be built from scratch or almost scratch in order to support the public API. For example, I personally need to build a Lucene-based search server (Solr and ES don't fit my use case). While I shouldn't need unit tests for Lucene itself, I do need unit tests to verify the threading model, file structure, and couple other things I write from scratch are correct because the complexity is so high and I don't trust myself or anyone else to write it correct the first time.