Managing regression

I'm an impulsive coder by nature and have started learning the virtue of patience the hard way in programming. One of the areas I fare badly is when I'm modifying existing code. If I don't have all the details laid out before me I invariably miss certain avenues that sometimes lead to regression. I'm okay in coding but underestimated maintenance of code until I read "Implementation Patterns".

So, my questio开发者_开发问答n is if you're maintaining existing code how do you cover all the bases and make sure you're not leaving potholes behind? What are the strategies you use when you're not sure where the code may break?

---

Unit tests, in brief. You need test coverage to ensure that when you make changes, you can rerun the tests and ensure that you've not broken anything.

If you have a continuous integration, then this will show up as/when you check in. I would check in early/often to make sure that your changes are small, and that you can easily track the causes of bugs.

The headache is retrofitting unit tests to an already existing framework. You'll probably have to reengineer some of the existing library in order to permit dependency injection and mocking. Unfortunately just making those changes is not without its risks, and this all points to writing the tests (and engineering your code to be test-friendly) as early as possible.

---

If you can figure out some edge cases, you can write some unit tests. Then, after the modifications, you can check to make sure that your tests still pass.

It's not fool proof, but it's better than nothing!

---

Unit testing, in a nutshell. One of the benefits of writing unit tests is that it can make refactoring/later code changes safer and give more confidence that those changes haven't broken anything.

Tie this in to a Continuous Integration environment, where the latest code is periodically pulled out of source control, built and then all the unit tests run, and you have pretty quick feedback in an automated fashion if any code changes break the build.