Code coverage for Integration tests

Question

Let's say that I have a project where most of the codebase is already covered with Unit Tests (using mocks). How many Integration Tests should I write then? The entire codebase is already covered with unit tests, so how much of the codebase should I cover again with integration tests? 5%? 100%?

I know that numbers always depend on a situation, so here is the stack that I use: I work on the web app using React, Node.js, Typescript + React Native for mobile. The product is not related to anything life-important (it's not a military, health-related project).

Answer 1

Some relevant guidelines:

• The goal is confidence, not coverage. If you have good coverage with well-written unit tests then a tiny number of high-level tests can be enough to have confidence that the overall system will Just Work™.
• Having both unit and integration tests for the same functionality is a waste of time in terms of writing the tests, maintaining them, and running them. Asserting the same thing in two different ways is unlikely to increase anyone's confidence of the correctness of the code.
• Using lots of mocks is a smell. It's hard to tell without looking at the code base, but it's often a sign of mixing side effects with functional code.
• When trying to minimize project cost by using the test pyramid, integration tests are something you write when there is no way to achieve the same confidence using a unit test.

Answer 2

Consider not using 'code coverage' as your metric

Because systems and integrations have different issues and failure points it is hard to measure code coverage across systems.

Code coverage, even for unit tests is a very rough guide and in my experience ends up, in reality being:

• You have to meet a metric, say 80% to get your code merged. This leads to low quality tests that assert true is true and when the internals fail give hard to diagnose error messages

• It often only tests 1 or perhaps 2 of the paths. I often use 'good, bad, blank, null, undefined as a set of test cases for my code. This adds value because I end up taking care of a lot of the corner and edge cases. Sometimes I call it "500%" coverage :) Often achieved (passing tests) with simple approaches such as parameter defaults so that subsequent operations on them don't raise errors (think 'substring of "" ' vs substring of undefined (error)).

What to use instead? Not sure I have an alternative other than walking through integrations and failure points as a team and making sure they are covered.

Answer 3

For integration you should prefer interface coverage to code coverage. You shall thus verify that all your units are called and with which values during your integration tests. Indeed, the units shall work correctly following your unit testing. The issue is to verify they are called correctly by other units. Remember nonetheless that you shall write functional tests. The coverage shall be used as a stopping and quality criteria, not as the objective of the integration tests.