I think the hardest part of starting with legacy code is that as novices you will write brittle tests, and that is likely to give you bad design as you redactor. It's really important that you go through the process of learning what good (non fragile, non brittle) tests look like and how to write them.
Keeping the tests informative (i.e. fail only for the right reason and do so quickly) requires deliberate effort either way. It is mostly impossible to write tests that aren¡¯t brittle around code that is. That is why I suggest strongly that you keep refactoring until you have a ¡°good OO design.¡± Defining that is a little bit complicated and probably belongs in its own thread.?
If you write brittle tests around brittle code and then say, ¡°Okay, it¡¯s covered. Now we¡¯re done,¡± then you either know less about design than you need to or you are in denial (It could definitely also be both.)?
The advantage of working with legacy code however is that you have better defined acceptance tests etc.
It depends how legacy your legacy code is. I have encountered systems where the requirements were defined in a document no one had read and what the code did was not what the document said. I have encountered other systems where the only requirement was that the system keep doing whatever it was that it did, and no current employee knew what that was.?
