Yup, I'd agree with that. These days I only use Unit Tests in a few very specific scenarios: 1) I like to write a 'nominal case' unit test because it helps me

Yup, I'd agree with that. These days I only use Unit Tests in a few very specific scenarios: 1) I like to write a 'nominal case' unit test because it helps me think about the sort of API that I want, and it let's me see the fun stuff up on the screen very quickly. 2) I've found a bug, so I write a unit test because apparently this bug was in code that I wasn't able to reason about correctly when I first wrote it, which means it is probably tricky - the unit test will stop regression. 3) When investigating a bug, and I want to assure myself that a subsystem is reacting the way that I expect it to, I sometimes write unit tests as a way of proving to myself that I have understood what is going on. I've seen other people write loads of unit tests for every single little thing, but it actually makes their code more rigid, as if you want to change an interface, you not only have to change the code in the product, but you have to change all of the unit tests too. The result is that people don't like changing what is written, and prefer to overlay a level of abstraction to avoid the rewrite, leading to less clear architecture overall.