> things like small one-liner functions for conditionals and basic arithmetic that are designed with mock- and test-ability in mind

I've done this before. It's very easy to want to make all your function/method calls work the same.

To stop, I applied the following rule whenever I had to choose between making a function static or mockable: does this function's name completely describe its implementation? Small methods like "StringUtils::isEmptyOrWhitespace" pass this test: it's just going to check if the string is empty or only contains whitespace, and that doesn't need to have its implementation swapped out. On the other side, "ImageUtils::detectFacesInImage" goes into no detail about how it does the face detection, and definitely needs an interface to test against.

That said, it all depends. You might allow your users to pick which characters count as whitespace, I don't know.

> I think integration and other coarse-grained tests are far more useful more often!

Yes! Integration tests are the "main" tests. Unit tests are secondary. Use them when you need to debug why your integration tests fail.