> I _really_ have to dispute the idea that unit tests score the maximum on maintainability. The fact that they are _so_ tightly tied to lower-level code makes your code _miserable_ to maintain.
I disagree to the point I argue the exact opposite. Unit tests are undoubtedly the ones that score the highest on maintainability. They are unit tests after all, meaning they are self-contained and cover the behavior of individual units that are tested in complete isolation.
If you add a component, you add tests. If you remove a component, you delete it's tests. If you fix a bug in a component, you both add one of more tests that reproduce the bug and assert the expected output and use all existing tests to verify your fix doesn't introduce a regression. Easy.
Above all, unit tests serve as your project's documentation of expected behavior and intent. I can't count the times where I spotted the root cause of a bug in a legacy project just by checking related unit tests.
> (...) a whole whack of integration tests at the boundaries of your services/modules (which should have well-defined interfaces that are unlikely to change frequently when making fixes), and a handful of unit tests for things that are Very Important or just difficult or really slow to test at the integration level.
If it works for you then it's perfectly ok. To me, the need for "a whole whack of integration tests" only arises if you failed to put together a decent coverage of unit tests. You specify interfaces at the unit test level, and it's at the unit test level where you verify those invariants. If you somehow decided to dump that responsibility on integration tests then you're just replacing many fast-running targeted tests that pinpoint failures with many slow-rumming broad-scope tests that you need to analyze to figure out the root cause. On top of that, you are not adding checks for these invariants in the tests you must change if you mush change the interface. Those who pretend this is extra maintainability needs from unit tests are completely missing the point and creating their own problems.
I think the whole problem is just terminology. For example take your comment. You start talking about unit tests and units, but then suddenly we're talking about components. Are they synonymous to units? Are they a higher level, or a lower level concept?
People have such varying ideas about what "unit" means. For some it's a function, for others it's a class, for others yet it's a package or module. So talking about "unit" and "unit test" without specifying your own definition of "unit" is pointless, because there will only be misunderstandings.
I disagree to the point I argue the exact opposite. Unit tests are undoubtedly the ones that score the highest on maintainability. They are unit tests after all, meaning they are self-contained and cover the behavior of individual units that are tested in complete isolation.
If you add a component, you add tests. If you remove a component, you delete it's tests. If you fix a bug in a component, you both add one of more tests that reproduce the bug and assert the expected output and use all existing tests to verify your fix doesn't introduce a regression. Easy.
Above all, unit tests serve as your project's documentation of expected behavior and intent. I can't count the times where I spotted the root cause of a bug in a legacy project just by checking related unit tests.
> (...) a whole whack of integration tests at the boundaries of your services/modules (which should have well-defined interfaces that are unlikely to change frequently when making fixes), and a handful of unit tests for things that are Very Important or just difficult or really slow to test at the integration level.
If it works for you then it's perfectly ok. To me, the need for "a whole whack of integration tests" only arises if you failed to put together a decent coverage of unit tests. You specify interfaces at the unit test level, and it's at the unit test level where you verify those invariants. If you somehow decided to dump that responsibility on integration tests then you're just replacing many fast-running targeted tests that pinpoint failures with many slow-rumming broad-scope tests that you need to analyze to figure out the root cause. On top of that, you are not adding checks for these invariants in the tests you must change if you mush change the interface. Those who pretend this is extra maintainability needs from unit tests are completely missing the point and creating their own problems.