To mix integration test coverage with unit test coverage is not a good idea. Please allow to see them independently again.
This is really needed please dont be so arrogant only because it does not fit in your coding concept. So dont ignore reality. There is a reason why this is requested in so many posts here. We want to see it differently because first of all the meaning is totally different between these coverages.
I will explain it:
We have at least 5 different stages of testing:
- Unit Tests based on JUnit + Mockito ( Each test is for a single class and ensures the functionality of the class, These tests are quick executable and mostly written by developers and run after any change to ensure functionality at class level), Whiteboxtesting
- Module Integration Tests based on JUnit + for example DBUnit or Mockserver. (Written by developers to ensure Module level functionality, (how classes work together) slower and usually only run on purpose or on the buildserver), Whiteboxtesting
- Devop-CI Tests. Ensure functionality of a software component containing different modules by running them against Mocked external services or by executing commands from external tools (like postmen,soapui,roboframework) These tests are performed by devops to ensure that the whole software package works as intended. Blackbox testing
- Quality Assurance Automated Tests, Performed by the QA with similar tools like the Devop-CI tests but with real data against real external services / devices. Blackbox testing
- Quality Assurance Manual Tests, Performed by QA Personal to ensure Quality of things which can not be tested easy automatically. Blackbox testing
The Coverage of all this together is somthing you can throw away it does not make any sense.
But coverage for each of them helps a lot!
Unit Test and Module Coverage: If the coverage on both is very low than bugs will appear more often at Devop-CI Tests which are more expensive and take more time to execute. So the development is interested to see the coverage of both to ensure that there quality is ok.
Devop-CI Tests: The devops are interested to also have a high quality of coverage especially for the software parts that are APIs for or to external services. If the Devop-CI Tests are too low than the QA will find more bugs this is more expensive because only releases are tested by our QA. And some test are also performed manual by persons not computers.
QA Automated Tests: The QA is interested to perform as much tests automatic, the QA tests are more use case specific so they do not try to cover the whole thing but specific use cases especially where interaction betweeen services and external components is needed. The QA tests multiple software packages together which all have there own Unit/Module/Devop-CI Tests. The test ensure that the use cases work so that the interaction betweeen all software components works. The QA Tests against a release bundle of all software products together. They have a high interest that most of there tests are automated because the rest of the test are done manual and that is expensive.
If i have 100% unit coverage but 0% in the other areas than the component is not good tested! It is very likely that it will fail. So usually we try to have something like 75% unit coverage 50% Module Coverage 40% Devop-CI Coverage and 30% QA Coverage.
Please give the possibility to allow some kind of tag for coverages so we can see multiple coverages. It was at least bettwe before 6.2 there was at least the IT Coverage and Unit Coverage.