I have to agree, and add an observation that every project I've seen which emphasised highly isolated unit tests spent the majority of its test development effo

I have to agree, and add an observation that every project I've seen which emphasised highly isolated unit tests spent the majority of its test development effort on local behaviour that was easy to test, and very little effort on testing complex interactions and emergent behaviour. Furthermore, when a complex interaction with changing behaviour in third party code caused a bug, I have always observed the resident advocates of highly isolated unit tests throw up their hands and say "oh well that's not our problem". I'll offer up my own rule that I've worked out over the years: the first test you write, from day one, should be the end-to-end performance stress test that fully loads a production deployment of the project, making it do everything all at once and sending random junk input until it falls over. Even when your project doesn't really have any functionality yet, run that one continually in the background. This one test will find so many classes of bugs that you weren't expecting - it optimises your tests for learning surprising things as soon as possible. You then start fleshing out your test suite to cover the things you learn. With some smart design, there will be a lot of shared code between your every-growing stress test and the suite of more targeted tests. You might find that you get down to detailed unit tests of every part of the code... but you'll probably find that you only need to bother with unit testing obscure conditions for the complicated parts. The core philosophical difference here is that I regard tests as a tool for learning and making the code better, not as a way to make myself feel happier. The biggest performance barrier I experience as a developer is not the seconds it takes to cycle through the tests, it's the weeks it takes to learn what I'm trying to build. I aim my tests at that target.