Nice analysis, and very good points, notably your observation that "system tests enable large refactors." But I'm going to _blaspheme_ and disagree with your last point that "unit tests are still important". You're just being kind to the true believers and avoiding flak; I get it. But unit tests are only important for testing isolated, specialized sections of code, code that's just too expensive to test at a higher level, which is maybe up to 5% of code, if that. Otherwise, (1) unit tests are expensive to develop (using actual software developers), (2) they are brittle (as you just proved) (and for what benefit?), and (3) they are almost always redundant; they have to be superseded by a higher-level test anyway (or the higher-level tests are incomplete). Do you have developer time to duplicate work? So why spend the resources? If we all gave up on the unit test religion, we'd have a lot more time for creating and refining actual functionality. Anyway, thanks for your great analysis.
I have never actually heard that perspective on unit tests before. I'll have to think about it more, but I think you are on to something. That said, unit tests might be more useful while constructing new code. They've legitimately helped me uncover bugs before earlier than a system test would have. You also have to consider that system tests can't be run until you have a working system.
Sure, you just said it very well: if you as the developer feel that unit testing will have value while developing, by all means, do so. _You_ are the best judge of how to maximize production of quality software. Have your unit test framework all set up and ready to use. Where it all goes wrong - and let's face it, we have all experienced this - is in two aspects: (1) the idea that you should get some high %age of test coverage with unit tests, say 70-80-100% (ridiculous and never attainable), and (2) that those original unit tests should be maintained (your analysis provides a superb, specific, valuable example of where that goes wrong). Instead, let the higher-level tests take over, because they are going to have to test all that anyway. And those tests can be made less expensive. The original religion of TDD was never truly attainable. Instead, we are either liars (because we don't really sustain the level of TDD we say we do) or we are self-loathing (because we don't ever even get close), or both. So, let's free ourselves now.
Nice analysis, and very good points, notably your observation that "system tests enable large refactors." But I'm going to _blaspheme_ and disagree with your last point that "unit tests are still important". You're just being kind to the true believers and avoiding flak; I get it. But unit tests are only important for testing isolated, specialized sections of code, code that's just too expensive to test at a higher level, which is maybe up to 5% of code, if that. Otherwise, (1) unit tests are expensive to develop (using actual software developers), (2) they are brittle (as you just proved) (and for what benefit?), and (3) they are almost always redundant; they have to be superseded by a higher-level test anyway (or the higher-level tests are incomplete). Do you have developer time to duplicate work? So why spend the resources? If we all gave up on the unit test religion, we'd have a lot more time for creating and refining actual functionality. Anyway, thanks for your great analysis.
I have never actually heard that perspective on unit tests before. I'll have to think about it more, but I think you are on to something. That said, unit tests might be more useful while constructing new code. They've legitimately helped me uncover bugs before earlier than a system test would have. You also have to consider that system tests can't be run until you have a working system.
Sure, you just said it very well: if you as the developer feel that unit testing will have value while developing, by all means, do so. _You_ are the best judge of how to maximize production of quality software. Have your unit test framework all set up and ready to use. Where it all goes wrong - and let's face it, we have all experienced this - is in two aspects: (1) the idea that you should get some high %age of test coverage with unit tests, say 70-80-100% (ridiculous and never attainable), and (2) that those original unit tests should be maintained (your analysis provides a superb, specific, valuable example of where that goes wrong). Instead, let the higher-level tests take over, because they are going to have to test all that anyway. And those tests can be made less expensive. The original religion of TDD was never truly attainable. Instead, we are either liars (because we don't really sustain the level of TDD we say we do) or we are self-loathing (because we don't ever even get close), or both. So, let's free ourselves now.