I don't do any fancy research but for my simple stuff, I've mostly given up on the idea of unit tests. I still use them for some things and they totally help in places where the logic is wonky or unintuitive but I see my unit tests as living documentation of requirements more than actual tests. Things like make sure you get new tokens if your current ones will expire in five minutes or less.
> Don’t test external libraries. We can assume that external libraries work. Thus, no need to test data loaders, tokenizers, optimizers, etc.
I disagree with this. At $work I don't have all day to write perfect code. Neither does anyone else. I don't mock/substitute http anymore. I directly call my dependencies. If they fail, I try things out manually. If something goes wrong, I send them a message or go through their code if necessary.
Life is too short to be dogmatic about tests. Do what works for your (dysfunctional) organization.
Assume but verify I think is reasonable for external dependencies. Meaning do not test them explicitly, but have tests that exercise rh external dependencies such that it will uncover at least major braking changes in the dependency. Cause such things do happen from time to time. And it is highly benficial to be able to update dependencies and be confident that nothing broke - much easier to stay up to date.
The original argument for unit tests was on semantic units (do a thing) and not code units (a function). The interface could be a class or a set of functions, but the idea was in part not to break it down further than needed or combine separate requirements into one tests.
I think code units / syntactic units became popular as a simplification of the original idea, people copying the style from examples and seeing it as a solution to their problems without actually understanding what the example was describing. Then it gets repeated over and over as "test individual functions" until the original idea is lost and most people haven't even heard of it.
Nowadays the original idea is partially described by black box testing.
If you are writing the standard library for a programing language than unit tests are useful. If you are implementing an algorithm for any other reason you should ask why isn't this in a standard library already. Sometimes your company will have good reasons for making their own standard library, sometimes you will bring in a third party algorithm library. Most coding though isn't making an algorithm it is using existing known algorithms to massage data. As such most code shouldn't be unit tested.
If you are making a standard library then you should be writing a lot of unit tests. However odds are that isn't your job.
> Don’t test external libraries. We can assume that external libraries work. Thus, no need to test data loaders, tokenizers, optimizers, etc.
I disagree with this. At $work I don't have all day to write perfect code. Neither does anyone else. I don't mock/substitute http anymore. I directly call my dependencies. If they fail, I try things out manually. If something goes wrong, I send them a message or go through their code if necessary.
Life is too short to be dogmatic about tests. Do what works for your (dysfunctional) organization.