This question already has an answer here:
In order to ask this question I need to define a couple of terms to ensure everyone reading it is on the same page:
- Unit testing is the testing of a single class with all dependencies mocked / stubbed in some sort of way.
- Integration testing, in this context, means integration of a selection of objects within a system with some potential mocked dependencies. For example external collaborators (such as a database or remote third party) may be mock but then internal systems may also be mocked (e.g. mock out the authentication mechanism to always work). The idea is to spin up some non trivially sized part of the system and verify it behaves.
- Functional testing is spinning up the system as a whole and poking it to achieve the desired results. For the purposes of this question it may be against real external coll
From the test pyramid perspective we should have 70% unit to 20% integration to 10% functional tests.
With the above out the way my question is as follows : I've worked in environments where there are a large suite of unit tests however bugs still surface at runtime due to insufficient integration testing / non existent functional testing. Even with excellent unit coverage of a given class how that class is actually used / how it is wired into the rest of the system typically contains more bugs than you can really catch at the unit level. Usually these bugs are detected at the integration / functional testing level.
Granted with unit tests you can put the system into more states and they tend to run a lot quicker but as a bug detector they fall down compared to integration / functional level testing that actually drives code paths. When I raise this point with others the usual response is to say "oh, the integration tests are actually finding unit tests you didn't write!", this seems valid at first glance but all it means is I'm now testing my code twice : once at the integration level with full coverage and once at the unit level where I can't be guaranteed of the level of coverage. However I need to maintain both sets.
My question is if integration test setup is kept to a minimum / abstracted away in a common test setup library then why not use integration tests as the 'first line' of testing over unit tests? What's the actual value of testing everything twice?