CODEWITHSUNDEEP
unit-testingtestingjunittdd
Michael W
Michael W

Reputation: 3555

How to test a legacy application (and adopt Test Driven Development) without introducing risk?

I have been asked to bring an old java based application up to date and inline with more current apps I have worked on.

One of the things we would like to introduce is Test driven Dev for any new enhancements.

The code unit test coverage is currently very low <20%

As someone new to the application I would like this percentage to be a lot larger to give me the confidence to make changes without introducing defects.

Problem is to get this percentage up, a lot of the code would require re-factoring to be testable.

So Re-factoring with such low unit test coverage could introduce issues, but to get the test coverage up you have to re-factor?!

Is there anyway to lower the risk when trying to do this??

Upvotes: 1

Views: 214

Answers (1)

Sean Landsman
Sean Landsman

Reputation: 7197

The low risk approach to this is to test & refactor is very small increments. You have to introduce as many tests that you can before modifying anything (not always easy), and then continue the process but including refactorin into the mix.

If you keep your initial refactoring to extracting self contained blocks of code into small self contained methods then the risk is low (not risk free, but low) and you can then test both the original method as best you can, but additionally test the extracted method thoroughly.

Mocking also helps a great deal with this - you're able to pass in mocks instead of real services etc which assists a great deal. You're still left with troublesome scenarios where the code is instantiating/calling a service internally that you dont want to test, but over time you can also work around this by introducing dependency injection (so that you can inject mocks instead of real services). But this is probably a longer term strategy.

The way I've done this in the past is to be pragmatic about it - initially is seems insurmountable, but if you do the above often and repeatedly in time you do end up with code you're no longer "scared" of. It takes time, but it can be done.

I can thoroughly recommend Michael Feather's Working with Legacy Code for this sort of thing - its offers many practical strategies in dealing with the very problem you (and we all experience, at some point) are facing

Upvotes: 8

Related Questions