it all depends on your definition of unit/integration, what I am talking about as unit tests you may very well be talking about as integration tests...
one of the main points I was making is you shouldn't have significant duplication in test coverage and if you do, I'd much rather stick with the unit tests and delete the others.
Because they catch more bugs than unit tests, are easier for our product team to understand, and rarely break when refactoring.
Even a simple business flow like registering a new user will touch half a dozen systems.
5 or 6 integration tests can cover this flow far better than 100 unit tests.
> and be smaller easier to understand/change tests
That’s not my experience at all.
Unit tests are generally much harder to understand and need to be changed much more frequently.
Where unit tests help in my experience is:
A) in pinpointing where in a complex bit of logic the bugs are.
B) for generic libraries and building blocks where you don’t know exactly how your users will actually use them.
Changed more frequently, yes.
Harder to understand is usually because they're not-quite-unit-tests-claiming-to-be.
Eg: a test for function that mocks some of its dependencies but also does shenanigans to deal with some global state without isolating it. So you get a test that only test the unit (if that), but has a ton of exotic techniques to deal with the globals. Worse of all worlds.
Proper unit tests are usually just a few line long, little to no abstraction, and test code you can see in the associated file without dealing with code you can't see without digging deeper.