Without Automated Testing, You Are Building Legacy
Without Automated Testing, You Are Building Legacy
This article introduces a blog series explaining the importance of test automation to build systems that will scale and adapt over time, rather than become outdated.
Join the DZone community and get the full member experience.Join For Free
I have worked with several different organizations in my career on initiatives to rewrite legacy applications. A common theme for each project was that the organization struggled to deliver both maintainable and "agile" applications.
As developers, we're curious by nature. I needed to understand exactly why this happens. In my contemplation of this common challenge, I discovered Automated Testing and became fascinated by it. I have since worked to include it as a central step as I write and maintain applications.
In this article particularly, I lay out how automated testing, or rather the lack there of, lies at the heart of many of the struggles we face as developers.
Note: This article is part of series in promotion for my new Pluralsight course, Effective Automated Testing with Spring.
Rewriting Legacy Applications
"Legacy" is a dirty word in our field. Legacy applications are notorious for being difficult to maintain, add new features to, and are using outdated technology. As these issues slowly build in severity, management eventually agrees to the rewrite.
A tiger team is formed, meetings are had, design documents produced, and the latest in technology and buzzwords will be used to rewrite the application. Developers are excited because working on code is fun again and they finally have the opportunity to correct all the mistakes made in the previous application. Business is happy because development is finally getting to their backlog of new features they have been requesting. Management is happy because this rewrite will help the bottom line.
After a few months of work, the new application is pushed to the production, ribbons are cut, release parties are had, and after a couple of emergency bug releases, the application is running smoothly in production. And for a time it was good.
Perhaps Not for Long
All too soon though, the good times come to an end. Developers get frustrated as the application becomes increasingly difficult to maintain, the backlog of new features to add begins to grow, and the technology used to build the application, cutting edge at the start of the rewrite, is now yesterday's news. Despite the best efforts of all involved, this application too has become legacy.
Over my career, I have worked with several different organizations either maintaining legacy applications or as part of a rewrite. When I have been a part of the latter, I have started to notice the early signs when a rewrite isn't going to deliver on the goal of a more maintainable and "agile" application. Despite the optimism from everyone involved in the rewrite, in the back of my mind I hear...
So Why Does This Happen?
Why do organizations consistently fail at delivering maintainable and "agile" applications?
This is a question that has bugged me throughout my career. At first, I thought it was the wrong people rewriting the applications. But having worked with some very talented developers during rewrites, lack of talent doesn't seem to be the problem.
I next thought a lack of planning might have been the problem. But having been part of the planning process, I doubt more or "better" planning would have helped.
A central theme in Continuous Delivery is shortening the feedback loop.
A developer makes a change; how long does it take for the developer and the wider organization to get feedback on on that change? At every organization I have been a part of, this process often takes hours, if not days. The developer pushes the change "over the wall" to QA, where typically a tester then manually validates if the developer's change is correct.
This process has two major problems. The first I already laid out: the feedback loop is slow.
The second problem is a bit more subtle, but much more damaging in the long-term. In this highly manual process, a developer could accidentally introduce a bug and the QA tester not catch it because they did not know to look for it. Organizations often attempt to address this problem, risk, by introducing additional processes. In my experience, however, these processes often only add more busy work without actually reducing risk.
Applications become legacy because it is too risky to refactor difficult-to-manage sections of code.
Applications become legacy because it is too risky to upgrade to new versions of frameworks.
Applications become legacy because it is too risky to introduce new features.
Automated testing reduces risk by giving rapid and broad feedback on if the application is meeting requirements and if any bugs have been introduced.
Introducing the Blog Series
Over this past year, I have taken the lessons I have learned over my career and worked with Pluralsight to share them in my tutorial Effective Automated Testing with Spring.
Producing Effective Automated Testing with Spring has been a fascinating and rewarding (even if at times difficult) process. I can honestly say on numerous occasions though, I have taken lessons learned from the content in my Pluralsight course and applied them to my day to day job and have seen the results first-hand.
To accompany the release of my tutorial (and help promote it), I decided to write this blog series that will serve as companion material to my tutorial covering areas that didn't quite make the cut for the video or drilling deeper into subjects than video sometimes allows for.
During this blog series, we'll look at common mistakes developers make that make testing harder, new developments in testing, like JUnit 5, and using tools to generate more value out of tests written, among other topics.
I hope you find this blog series useful. If you do, I hope you check out my tutorial on Pluralsight, as well.
Published at DZone with permission of Billy Korando , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.