views:

66

answers:

3

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 question 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?

+4  A: 

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.

Brian Agnew
Thanks, Brian. Guess I need to improve on UT.
Sidharth Panwar
A: 

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!

Denise
In fact, if you developed the code using TDD, then there _is_ no code not covered by unit tests - the code would not have been written unless it were necessary to satisfy a failing unit test.
John Saunders
John -- the change might be due to a change request and not neccessarily due to a bug. I've had tough experience with MS Datagridview due to last minute change requests.
Sidharth Panwar
A: 

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.

AdaTheDev