I'm the author of that article. I actually have a blog post in the works that addresses your concerns fairly directly, since they are concerns for me too. Keep an eye out for it. In brief, I recommend you buy a copy of Working Effectively With Legacy Code immediately, then work to get unit tests in place. Make sure you have a couple of tests for each public interface in the system. Once you have rudimentary test coverage, it becomes easier to refactor things without worrying so much about breakage.
That makes a lot of sense. I'll get the book and look out for the post. But I was wondering: does it make sense to have classes implement interfaces specifying public exposure of methods, but contain public methods that are there only to be accessed by the tests?
That is, the interface specifies a public method getIdentity() that returns an _identity_ object, but the class has getName(), getIDNumber(), that are public (so we can test them) but not declared in the interface? Do people do things like that?
I'm the author of that article. I actually have a blog post in the works that addresses your concerns fairly directly, since they are concerns for me too. Keep an eye out for it. In brief, I recommend you buy a copy of Working Effectively With Legacy Code immediately, then work to get unit tests in place. Make sure you have a couple of tests for each public interface in the system. Once you have rudimentary test coverage, it becomes easier to refactor things without worrying so much about breakage.