With these definitions, a Refactoring Ratio of undefined is ideal (lots of code changes, with no test changes). But a fractional Refactoring Ratio value between 0 and 1 is bad as it indicates code changes require significantly more testing.
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)