My own take on this is that it is hard to crystallise why or what a "unit" is. My cop out is it comes down to experience - once you've done this enough and solved enough problems and worked on enough teams, you'll get an intuition on this as it is more art than science.

I find it to be some mixture of importance and complexity, while always balancing against the single responsibility principle. A simple `average` function might be trivial but if it's important to your business logic you probably want to test that separately, even if it is nested within a "unit".

I find that following some iteration of "functional core imperative shell" helps here as it helps keep your core business logic to being data transformations and transformations on data are easy to test and their concerns are easy to reason about.

This then helps me reason about what is "implementation" and what is a contract/interface which should be tested robustly.

I guess really the art of writing just enough unit tests is to identify the seams and boundaries of your abstractions in your codebase, and potentially accepting that business seams in your codebase may be different from the seams of your actual software domain -- the latter being possibly more granular.