I remember once when I was about to try out a new way of rounding monetary amounts in a big application. The rounding routine was low level stuff, called from the entire program. Ideally the outside API wouldn't change that much.

So I changed the routine (which wasn't a refactoring, but a minor but actual change in logic) and ran the test suit.

Only two out of maybe twenty sets contained failing tests. Hmmm... is this a good thing or a bad thing?

A little of both. It was a good thing, because my change broke very little of what I had bothered to test. But this also showed I had a blind spot in the tests wrt what I just changed, and had I written tests at a more detailed level, more tests probably would have failed. I had to write more tests to verify what I expected from the program. Without a test suite... eh, I don't even want to think about that.

My story is related to refactoring.

When you refactor, you increase your general knowledge about the code, and in what ways it may need to be further tested. This happens when looking for refactoring opportunities and while changing the code.

So if you know your tests and your code you'll hopefully understand where you may be vulnerable, and you can add tests, before, during and after you refactor to counter that.

/J