Legacy COBOL systems face testing hurdles due to absent standard tools and complex customizations, prompting reliance on Java-based APIs for streamlined unit testing and integration with modern tools like SonarQube. Efforts focus on bridging legacy and modern processes through custom Java solutions, aiming to reduce technical debt and improve maintainability while navigating bureaucratic and implementation challenges.

Software Testing Unleashed

Software Testing Unleashed - hosted by Richard Seidl. Different guest per episode. The official Show notes contain a comprehensive overview of the episode. Released as audio and video.

• https://www.richard-seidl.com/en/testing-unleashed
• https://www.youtube.com/playlist?list=PL48Mbm-L0hjB1OdwYi9h7jrq9t352-Zk_

Episode Details

• Show Notes: https://www.richard-seidl.com/en/podcast/cobol-unit-testing-mainframe
• Published: 2026-06-04T04:00:00Z
• Duration: 00:24:04
• Author: Richard Seidl | Software Development & Testing Expert

Overview

The podcast discusses significant challenges in testing legacy COBOL systems, particularly the absence of standard unit testing tools and the complications arising from extensive customizations over time, which have created a complex, interwoven system. Developers found Java-based APIs more effective for unit testing, despite COBOL being their primary language, as the Java tools offered intuitive, minimalistic interfaces with features like follow-the-brackets syntax, simplifying test logic and assertions. Efforts to transition from custom solutions to standard practices involved integrating tools like SonarQube and X-Ray, though this required bridging legacy systems with modern processes to ensure consistency. The discussion also highlighted concerns about over-testing, emphasizing the need to balance rigorous testing with agility to avoid unnecessary delays in development cycles.

A key focus was the development of a Java-based unit testing tool for legacy Cobalt systems, designed to interface with external tools like Cucumber, Jenkins, and X-Ray, reducing reliance on custom solutions. This tool translates Java-written unit tests into debug scripts compatible with mainframe debuggers, enabling features like breakpoints and value checks. However, implementation faced hurdles, including prolonged delays in securing technical approvals and service accounts for mainframe access. The customization strategy aimed to create a bridge between mainframe systems and standard tools, with long-term goals of replacing the tool with a standardized solution, as no equivalent IBM tool currently exists.

Future objectives include refining the testing interface for non-Cobalt developers, integrating REST APIs to convert JSON inputs into Cobalt bytecode, and optimizing legacy systems by reducing technical debt through modular testing. Broader goals emphasize simplifying COBOL programs, improving maintainability, and encouraging teams to address aging software infrastructure. The approach underscores the importance of adapting modern testing practices to legacy systems while fostering collaboration between developers and stakeholders to overcome technical and bureaucratic barriers.

What If

• What if you built a Java-based unit testing interface for legacy COBOL systems?

  • Move: Develop a Java API that translates unit tests into COBOL debug scripts, integrating with Jenkins and SonarQube.
  • Why Now?: Legacy COBOL systems lack standard testing tools, and Javas structured syntax reduces complexity for developers.
  • Expected Upside: Enable modular testing with minimal customization, speeding up releases and reducing technical debt.

• What if you prioritized REST API integration to bridge COBOL and modern tools?

  • Move: Create a REST service that converts JSON inputs into COBOL bytecode for execution.
  • Why Now?: Legacy systems require seamless integration with mainstream tools like X-Ray, and REST APIs offer universal compatibility.
  • Expected Upside: Facilitate non-Cobalt developers (e.g., QA teams) to test systems without learning COBOL syntax.

• What if you focused on simplifying test assertions using Javas structured syntax?

  • Move: Refactor Cobalt test cases to leverage Javas literal-based assertions (e.g., expect(variable == 10)) via the existing Java API.
  • Why Now?: COBOLs plain-text assertions are error-prone, while Javas IDE support improves clarity and reduces boilerplate.
  • Expected Upside: Accelerate bug detection with readable tests, reducing over-testing and aligning with agile workflows.

Takeaway

• Adopt Java-based unit testing for COBOL systems by leveraging intuitive Java APIs (e.g., follow-the-brackets syntax) to write concise, readable test cases and assertions, reducing reliance on custom COBOL test tools.
• Integrate with standard tools like Jenkins, SonarQube, and X-Ray to streamline testing workflows, ensuring compatibility with mainstream CI/CD pipelines and code quality metrics.
• Prioritize modular testing by developing a bridge tool that connects mainframe systems to external tools, enabling component-level testing instead of monolithic debugging.
• Advocate for managerial support to expedite technical approvals and service account access for mainframe systems, reducing bureaucratic delays during tool implementation.
• Design user-friendly interfaces for non-Cobalt developers using REST APIs to translate JSON inputs into Cobalt bytecode, improving accessibility for QA teams and reducing dependency on niche expertise.