Ask HN: With integration tests, what's the point of unit testing?
When initially putting together pieces of a system, unit testing is great. No argument there. But once you have one (or ideally many) end-to-end tests in place, what's the point of unit testing?
It would seem to me that unit tests should be removed in favor of integration tests that cover the same situations. Like a type of calcification where unit tests are created for new features and then slowly get rolled into new integration tests before the cycle repeats and new features and their new unit tests are added.
/All moot again if your integration tests take > 10 minutes to run
1 comment
[ 39.4 ms ] story [ 138 ms ] threadThere would be fewer integration tests that test larger units and even fewer service tests that test a complete artifact.
Even fewer than that would be end-to-end tests that test multiple artifacts in an environment.
An entire application system could have as few as 5 - 10 journey tests that run within a minute and continuously assert that the most fundamental user actions are working. Any failure would be an alarm.
Each level of test has a different focus. I do agree that when a system is 'done' that unit tests have the least value. However a system is never 'done' and there are always changes made to it. If unit tests get in the way of desired refactoring, by all means throw them out and make new unit tests for the re-implementation.
The other good value of having unit tests in your codebase is that existing tests serve as great patterns from which to create similar new unit tests. Finally unit test coverage can also serve as documentation to onboard new developers in a new area where the even just the names of the test cases can help understanding of a component.