
Ask HN: With integration tests, what's the point of unit testing? - noobiemcfoob
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&#x27;s the point of unit testing?<p>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.<p>&#x2F;All moot again if your integration tests take &gt; 10 minutes to run
======
karmakaze
The idea is that testing is a pyramid with lower level (unit) tests having
high coverage and running very fast.

There 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.

