Martin Fowler says that we should do refactoring before adding new features (given that the original program is not well-structured).
So we all want to refactor this dirty codebase, that's for sure. We also know that without unit-testing code it's very easy to introduce subtle bugs.
But it's a large codebase. Adding a complete suite of tests to it seems impracticable.
What would you do in this case?
Unit tests can be performed manually or automated. Those employing a manual method may have an instinctual document made detailing each step in the process; however, automated testing is the more common method to unit tests.
Tightly coupled code is extremely hard to unit test (and probably shouldn't be unit tested - it should be re-factored first), because by definition unit tests can only test a specific unit of something. All calls to databases or other components of the system should be avoided from Unit Tests because they violate this.
My suggestion would be that you touch as little as possible and add what you need. I have found that it is best to leave well enough alone, especially if you are on a tight deadline.
If you had had unit tests, that would be a different story, but when you change code it can be like touching a spider web. Changing one thing can affect everything else.
Let me recommend the book Working effectively with legacy code by Michael Feathers. It contains a lot of realistic examples and shows good techniques for tackling the legacy code beast.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With