They key problem is the number of combinations of inputs, outputs and state. And since its difficult to set up state correctly in such an api-based test, then t

They key problem is the number of combinations of inputs, outputs and state. And since its difficult to set up state correctly in such an api-based test, then the tests invariably end up using the api to initialize state. So that means we're dealing with the permutations of inputs, outputs and state, not merely the combinations. Basically anything more complicated than a "unit" is impossible to test for every permutation and as a result you get bugs when things happen in production that nobody anticipated a test for. In short, been there, done that. Yes, way easier to write less tests that don't test everything. Witnessed plenty of six figure+ bugs as result. Meanwhile, if refactoring means breaking a load of tests then you're doing it wrong. TDD is actually pretty hard to learn and it seems to me most people give up when the have to refactor code that they've tested internal details. Given their knowledge they conclude TDD is bogus, rather than wonder if perhaps their tests are bogus.