Refactoring Legacy Projects: Scaffolding Technique
If you’ve inherited a Legacy Project (project without any tests) and say you want to enhance an existing feature, where do you start?
In such situations, I find myself building some form of workflow tests (scaffolding). I start off using a record and play back testing tool to record couple of scenarios for the feature, I want to enhance. Most often, I would take the recorded tests and covert them into a re-entrant, independent scripts. So that I can execute them over and over again, without needing manual intervention. Basically this would mean, automating the set up and tear down of the application’s external dependencies like data-stores, email servers, etc correctly. This should not take more than a couple of hours to configure.
This helps me build the initially safety net to start off. This also gives me a decent understanding of how the feature works. Now I can go inside the code, change something really small and see what impact it has on my tests. Some times I tweak my test to see what impact it has on the feature. Basically I’m using this test as a probe to gain deeper understanding of the feature’s functionality.
Doing this give me some confidence to jump in and start refactoring the code, so that I can create an inflection point, break dependencies and start writing unit tests around the core of my feature. In couple of hours, I should be able to build a solid safety net, around my feature using unit tests and/or business logic acceptance tests.
At this point, I almost always, go and delete the initial workflow test that I had built. This is the reason, I call this approach as the scaffolding technique.
- Build some initial workflow tests to help you get in there,
- Make the necessary code/config changes to write direct tests
- Gradually build a solid safety net around the feature
- The scaffolding (initial workflow tests) did its job, now its time to throw them away
