In this screencast I take a small piece of legacy Java code that contains the most common problems found in much larger legacy code bases. The objective is to first write tests to understand what the code does and then refactor it to make it better. The code contains Singletons, static calls and behaviour that does not belong there. It also has some design issues.
As an advice, I always recommend that we should never "touch" the production code as we retrofit tests, that means, we should not change it typing into the production file. However, as normally legacy code is not written with testing in mind, sometimes we need to change the production code in order to write tests for it. I address this scenario explaining how we can do that in a very safe way.
A common question when developers want to make legacy code better is "Where do we start?" I also address that explaining the how the approaches for testing and refactoring legacy code are the opposite from each other.
Besides a few other things, I also cover the use of code coverage tools to help us testing the code, how often we should be committing, how to fix a possible problem with the design in very small steps and how to stay in the green while refactoring our code.
Last but not least, I show how our tests and production code be easily written in a way that it captures the business requirements.
Although it is a bit long, I hope you all enjoy it.
There are two minor things I forgot to do while doing this exercise. Let me know if you spot it. :)
As an advice, I always recommend that we should never "touch" the production code as we retrofit tests, that means, we should not change it typing into the production file. However, as normally legacy code is not written with testing in mind, sometimes we need to change the production code in order to write tests for it. I address this scenario explaining how we can do that in a very safe way.
A common question when developers want to make legacy code better is "Where do we start?" I also address that explaining the how the approaches for testing and refactoring legacy code are the opposite from each other.
Besides a few other things, I also cover the use of code coverage tools to help us testing the code, how often we should be committing, how to fix a possible problem with the design in very small steps and how to stay in the green while refactoring our code.
Last but not least, I show how our tests and production code be easily written in a way that it captures the business requirements.
Although it is a bit long, I hope you all enjoy it.
There are two minor things I forgot to do while doing this exercise. Let me know if you spot it. :)
5 comments:
That's really cool and useful!
Thanks
Sandro
Great screencast Sandro! Thank you.
Are you planning to do more?
Yes, I'm considering to do more in the future. Probably when I finish my book.
Thanks for your comment Callum
Great screencast Sandro. One question if I may.. How to test legacy code when part of the logic is spread in UI, stored procedures, services, etc.? I think this is the scenario you mentioned to change the code before testing it ("when the code is not prepared to be tested"). Is that right?
Tks a lot and congrats for such an intersting screencast.
Sandro , There are many TDD + Java +Refactoring example videos out there on youtube, Yours was the only one that was really so smooth flowing that it made me spend more than 1 hour to follow . What book are you writing now ( from your comment made on 13th April 2013. Would be keen to find out . Eagerly await your next video . In the meantime I am passing the link to many of my friends . Thanks - Kasi
Post a Comment