Refine Code Refactoring Maturity Score so that increasing unit test coverage doesn't have negative impact

[amclin]

Code Refactoring scores will look bad if a release or a file adds unit tests to cover existing code. In effect, this is technical debt (uncovered code) being paid down, but it will cause a good thing to show up as a detrimental indications on the metric.

A significant increase of code coverage without accompanying code changes will reflect as a dropoff when monitoring Code Refactoring Maturity.

Need to figure out a way to refine Refactoring Ratio Maturity in order to eliminate this noise factor. One way to do this is procedural: ignore any releases that are only increases in unit tests. They could be identified by having Refactoring Ratio values of 0 (0 code changes, divided by a defined number)

https://github.com/amclin/devopsculture/blob/master/_kpis/code-refactoring.md#todo-future-refinement