I had a question on what is the correct way to handle legacy code that is inherited by the team that has no unit and integration tests? How does the team confirm that any new feature being developed has not introduced regression into the legacy code base? Should the team spend time in developing integration tests for legacy code before new features are implemented?
These questions generated lots of good discussion at the AgilePalooza session. I was surprised that there are no simple answers to these questions. Most of Agile projects, according to the speakers experiences, start fresh. I tend to agree with the exception that, there will be instances where it would be easier to inherit ready made modules rather than develop from scratch.
Here are some possible answers that came out of the discussion panel
- Don't worry about legacy code too much. Ensure all new development happens with Agile/Scrum practices i.e. proper unit tests and Integration tests, etc...
- Dedicate some time in every iteration for performing manual testing to catch regressions.
- If you are working on Legacy code during new feature development, take some time to organize that area of the code. Add unit and integration tests for that part of the code .With time the code can be re-factored and overall test coverage can be improved.
- The most convincing answer according to me is - Encapsulate legacy code into end to end functional/integration tests before new feature development begins. For any new feature under development these tests would help determine if any functionality is broken.
In short, there's no textbook definition of how legacy code should be tackled in Agile development. Each project team has to analyse and make a decision for themselves on how much they want to invest upfront to tackle legacy code that would help them be more agile.
0 comments:
Post a Comment