unit vs integration tests is not an either/or. you need both, and in appropriate coverage amounts.
a common way to think about this is called the "test pyramid" - unit tests at the base, supporting integration tests that are farther up the pyramid. [0]
roughly speaking, the X-axis of the pyramid is number of test cases, the Y-axis is number of dependencies / things that can cause a test to fail.
as you travel up the Y-axis, you get more "lifelike" in your testing...but you also generally increase the time & complexity it takes to find the root-cause of a test failure.
many times I've had to troubleshoot a failure in an integration test that is trying to test subsystem A, and it turns out the failure was caused by unrelated flakiness in subsystem B. it's good to find that flakiness...but it's also important to be able to push that testing "down the pyramid" and add a unit test of subsystem B to prevent the flakiness from reoccurring, and to point directly at the problem if it does.
> Unit tests have limited benefits overall, and add a bunch of support time, slowing down development
unit tests, _when done poorly_, have limited benefits, require additional maintenance, and slow down development.
integration tests can also have limited benefits, require additional maintenance, and slow down development time, _when done poorly_.
testing in general, _when done well_, increases development velocity and improves product quality in a way that completely justifies the maintenance burden of the additional code.
0: https://martinfowler.com/articles/practical-test-pyramid.htm...