Archive for the ‘spring mvc’ tag
Frequent upgrades will minimise your project’s tech debt – a Spring 2.5 upgrade experience
On my current project we upgraded from Spring 2.0 to Spring 2.5. The upgrade was almost as simple as dropping in the new Spring jar. As of Spring 2.5 the web MVC component has been split out into its own module, so now you need to include spring.jar and spring-webmvc.jar in your project lib directory. Also the mock module has been renamed to spring-test.jar.
The project compiled after the new jars were dropped into the project, but a couple of tests broke when running the Selenium functional tests during the build process. Upon further investigation we found that the suppressValidation(HttpServletRequest request) method in BaseCommandController had been deprecated in Spring 2.5 and was no longer called in the BaseCommandController class, so our controller that overrode that method was not being called. The fix was simple, we just overrode the suppressValidation(HttpServletRequest request, Object command, BindException errors) method signature and all functional tests were working again.
All in all the upgrade was quite easy which shows that the core Spring developers are doing a fantastic job at building an excellent framework. The experience also proves that writing tests gives you more confidence when it comes to upgrading your application’s module dependencies. If you have good test coverage then you will know early on in the development cycle of any change in behaviour that an upgraded module dependency may have on your application. So you don’t have to wait until UAT or worse, after the application goes live, for the change in behaviour to be raised as a defect.
On previous client projects that I have worked on, I have found applications that still used Java 1.4 and old versions of module and library dependencies. Not surprisingly these applications had poor test coverage which led me to believe that there is a high correlation between old and stale code bases and poor test coverage.
Therefore one of the reasons that a code base becomes outdated is due to fear, uncertainty and doubt (FUD) of what might happen to the application after an upgrade. If you don’t have any tests then the greater the cloud of FUD becomes and an increasing reluctance to upgrade application dependencies. Upgrades of project dependencies are necessary for developers to make use of new features, and to benefit from bug fixes and performance improvements. Avoiding frequent upgrades will incur a cost that we call tech debt, and it means going without the new features, bug fixes and performance improvements that a newer version of a library or module dependency provides. This leads to a reduction in productivity and quality that eventually translates into a dollar cost amount to the business.
The message is simple: write tests so that any change in application behaviour from future upgrades of module and library dependencies can be detected and resolved early in the development cycle. Do not ignore upgrades, as this will only add to your tech debt, and with any debt that doesn’t get serviced you end up paying a greater cost as time goes by.
