If you work for a company of significant size, or one that has simply been around a while, odds are good that you’re running COBOL. Perhaps lots of it. And, if so, you likely wish that you could update it to something else, but find the risks often outweigh the rewards. I recently wrote about a major Midwest pension fund with hundreds of billions of dollars under management, and how it was trying to migrate much of its COBOL code to a more modern programming language, Java. They wanted more flexibility and speed in adding new features to keep up with customer demand for more retail-like computing experiences. They wanted to go full DevOps.

SEE: Quick glossary: DevOps (TechRepublic Premium)

But wanting didn’t make it so. Unit tests offered them a path forward.

The writing of unit tests is central to planning any code migration initiative. Unit tests, said Dan Wahlin, serve as a sort of crystal ball because they enable you to “more accurately predict future changes [to your code] and the impact they’ll have.” A lot of large institutions run a lot of COBOL, but almost no one at those companies really understands anymore how it all works. Given the gargantuan quantity of code running in production today (an estimated 92 billion lines of new code written each year), most of it lacking unit tests, this turns out to be a big problem for enterprises that want to safely upgrade their systems. 

Given the scale of the unit testing problem, the only viable path forward may be to automate those tests.

Automation, but not with robots

The rise of artificial intelligence solutions like Diffblue can automate unit test writing in human, readable output. This is critical as we are never going to have enough developers to write all the code we need going forward, especially tests. AI is used in cars, medicine, online dating, social media and more, yet developers have only just recently started to use it for testing. With Diffblue and others offering such testing for free, it’s becoming ever easier to determine if automated testing will work for your particular applications. 

It’s important to start now.

SEE: Hiring Kit: JavaScript Developer (TechRepublic Premium)

In my article, I referenced a glaring example of mainframe failure–the New Jersey state government website for unemployment filings. Everything worked great until it didn’t. As it happened, too many customers rushed online in January 2020 as governments and banks closed offices or restricted hours in response to COVID, crashing the site. Turns out it wasn’t COBOL or the mainframe’s fault. Rather, it was the web application between the mainframe and the outside world. Applications written in COBOL are mostly so old now that they’re pretty well debugged. They’re rock solid and just as inflexible as stone for many new use cases.

Therein lies the problem. 

COBOL is more than half a century old. There are 280 billion lines of COBOL working every day (it’s the backbone of our global financial systems). It works. It works because we’ve spent decades honing it for particular use cases. Programming languages are designed with a bias. Python shines for data science and artificial intelligence. Fortran is unsurpassed at rendering math formulas in code. JavaScript makes websites interactive. But almost nothing beats COBOL for crunching billions of transactions.

SEE: 10 ways to prevent developer burnout (free PDF) (TechRepublic)

Despite COBOL’s reliability, any effort to update to a new language, as in the example cited above of the Midwest pension fund, creates some uncertainty. Of course, you don’t need to be updating a system to have the chance of application failure. What happens when the day comes with a new bug discovery in your program but the author is no longer employed on your team? A new team member needs to understand the code and make sure she doesn’t break the program with a fix. With unit tests, this is much easier, faster and more reliable.

Unit tests also help in code reviews. And if the overall code base has good test coverage, it can be much easier to understand the larger picture, improve the program and avoid other bugs. Whatever your programming language, and whatever the application, unit tests are sometimes eschewed because they slow software development down. Sometimes slowing the pace to be more deliberate through unit tests actually speeds everything up.

Disclosure: I work for MongoDB, but the views expressed herein are mine.

Developer Essentials Newsletter

From the hottest programming languages to the jobs with the highest salaries, get the developer news and tips you need to know. Weekly

Sign up today

Also see