If you start with a system that has no tests, don't get focused on a ridiculously high number. I worked on a system that had 16 percent coverage when I picked it up. A year later, I had worked it up to 65 percent. This was nowhere near 100 percent, but the quality of the system had grown by leaps and bounds due to Capturing a bug in an automated test and Harvesting metrics.

At one time I was discussing the quality of my code with my manager, and he showed me a report he had developed on his own. He had run a code counting tool on every release of every application he was overseeing. He said my code counts had a unique shape. All the other tools had a constant increase in lines of code. Mine had grown, peaked, and then started to decrease and was still on the decline.

This happened despite the fact that my software did more than ever. It's because I started throwing away unused features, bad code, and clearing out cruft during refactorings.

By slowly building an automated test suite, you will gradually cover more of your code. By keeping a focus on building quality code with corresponding tests, the coverage will grow naturally. When we shift to focusing on the coverage reports, we may grow the numbers quicker, but it will tend to be more artificial.

From time to time, as you Cash in on your confidence and rewrite chunks, you should feel empowered to throw away old junk. This will also grow your coverage metrics in a healthy way.

All of these factors will lead to increased quality and efficiency. While your code may eventually peak and then decrease, it isn't unrealistic for it to eventually grow again due to new features. By that time, the coverage will probably be much higher, because now you are building completely new features, hand in hand with tests, instead of just maintaining legacy parts.