From Legacy Code To Testable Code–Introduction

This post was taken by raiders to the Everyday Unit Testing site. Follow Indy there!

It is the starting post about refactoring legacy code in order for unit testing it.

2 comments on “From Legacy Code To Testable Code–Introduction”

  1. rliesenfeld Reply

    I don’t think that JMockit (a mocking tool more powerful than PowerMockito) has a performance problem. It certainly seems fast enough to me.

    As for “code lock-down”, please try and provide some real evidence, rather than just hand-waving.

    The actions/refactorings you listed are all fine, as long as they are done for valid reasons, not just as workarounds for technological limitations, specially if said limitations can be avoided through the proper testing tools.

  2. Gil Zilberfeld Reply


    Thanks for the comment. I understand it well, since I also gave (and continue giving it), having worked at Typemock on mocking tools that don’t require changing the code. My aim is for well designed code, whether using with Mockito or JMockIt. Once you select the tool, you should continue on that path. Refactorings obviously help, and as you know, extracting a method for the sake of mocking 1 method rather than 5, is good for both testing purposes and usually the comes back better.

    I’ll write a post on lockdown in the future. But in a nutshell, the more powerful the mocking tool, the more coupling between the code and test increases. You’ve probably heard it in “you misuse the tool” form (I know I have many times), but it does happen. Once this coupling happens, and you have a working test, it becomes a question of convenience whether to modify the code or keep it like that, just that I wouldn’t need to change the test.

    Yes, it’s never the tool, it’s the programmer. And yes, I’ve seen many tests and code remain the same once the test passes.

    PS Nice work on JMockito!


Leave A Reply

Your email address will not be published. Required fields are marked *