2

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

3

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.
2
  • 1
    what do you mean by "minimize project cost by using the test pyramid" ? the pyramid is more about feasibility than cost- it's almost impossible to achieve same coverage using only high level tests – Rsf Jan 7 at 11:00
  • @Rsf flexibility decreases and cost increases in down to top direction , it takes more time to execute UI test , debug and find root cause , more time to fix all this are directly related to number of working payable hours required . So it is related to cost too – PDHide Jan 7 at 12:03
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.