We are using Datacenter edition (v. 9.9.1) and we have defined 80% of coverage for new code. We have set our new code as: reference branch (master).It turns really difficult to continue with this level of coverage. sometimes, we need to refactor or modify some legacy code (not coverage at all or maybe around 10-20% of coverage). Our Architect leaders want to have something to ensure we are not going below what we have in the previous execution. is this possible?
Ex:
we have the file : my_legacy_file.cpp where the coverage is 5%
I modify the file to change a method.
After that, this legacy code turns in new code (I can´t afford to have the 80% of this file covered by test), but I want to assume that if the coverage is 5% or higher is ok for my project. is that possible?
As you can understand is not a problem with a file, because if so, we could skip that file. We would like something general when several files are impacted.
What you’re looking for is the Clean as You Code methodology. When you edit the method in the existing file, you shouldn’t need to cover the entire file to 80%.
With Clean as You Code, you focus on making sure the changes you make today are clean and covered. That means that you would only need to cover your changes.
Talk to whomever controls your Quality Gate conditions and get them to focus the Quality Gate on new code metrics. Then you’ll only need to add tests for your changes, not the entire file.
Thank you so much for your clarification. Maybe I am missing something because we already are following the clean as you code strategy.
AFAIK this strategy allows you to focus on new code, but if you refactor a variable inside this old code, all the file becomes new code. This is my feeling but is not aligned with what you have explained me before. If you confirm that this is the behaviour expected, I will run some extra test.
I will give you some details more: we are using as new code (reference branch master).
This deserves a closer look because only the lines you changed should be marked as new code in this situation. Unless you maybe have some automated process in the background that’s changing all the tabs to spaces (or vice versa) and thus updating every line?
Just to clarify a bit more about the motivation on top of what Jose Luis mentioned - we are working on a repo which contains a lot of legacy code, many source files are too costly to be covered in the unit testing, however when people doing small changes on those files, e.g. adding/removing some parameters from a funcion, they are failing the coverity criteria.
So our questions are:
is that possible to have such rule, in which if a source file doesn’t have any unit test covered in the base version, don’t gating on it for new commits. So any change made on it would pass the coverage test.
or if we could configure a rule so the coverage check would pass as long as the overall coverage rate doesn’t decrease. In this case the changes on non-covered codes shouldn’t failing the coverage check because those codes are not covered in the previous version.
