Have you heard of the ideas in https://www.destroyallsoftware.com/screencasts/catalog/funct...? Essentially, his position is that it's only worth unit-testing those tricky bits, and the rest is inherently not worth unit-testing, because you'll almost-certainly embed the same assumptions you're attempting to test into the tests themselves.
In other words, I agree with you, but would question why you're even _trying_ to unit-test those other areas that aren't conducive to unit testing.
Yes, I've heard of the idea of functional core, imperative shell. In fact, that's how I write most code these days. But I don't think I've watched this talk before, so it just went straight into my todo list.
> In other words, I agree with you, but would question why you're even _trying_ to unit-test those other areas that aren't conducive to unit testing.
Well, other people make funny looks at me when they see how little tests I write...
No, but honestly, I see so much advocacy towards writing lots of tests, or even starting with tests, and so I'm trying (and failing) to see the merit of this approach in the stuff I work on.
> you'll almost-certainly embed the same assumptions you're attempting to test into the tests themselves.
That was my main objection when I was on a TDD course - I quickly noticed that my tests tend to structurally encode the very implementation I'm about to write.
In other words, I agree with you, but would question why you're even _trying_ to unit-test those other areas that aren't conducive to unit testing.