Creating unit tests for COBOL is still one of those tasks that sounds simple in theory, but becomes time-consuming very quickly in practice. That is exactly why we started building CutGEN: to make the generation of COBOL Check compatible .cut files faster, easier, and more practical with AI support.
In our earlier post on CutGEN – Intelligent Unit Test Generator, we introduced the first version of the tool. At that time, the workflow was based on Generate_tests.py and Run_tests.py to generate and execute unit tests.
Since then, the tool has evolved significantly.
From Script-Based Workflow to MCP Server
Today, CutGEN is an MCP server, and its responsibility is now much clearer: generating the .cut file.
Instead of relying on a script-based local workflow, the generation is now exposed through MCP, which makes it easier to integrate into modern AI-assisted development workflows. This also makes the role of the tool more focused:
- CutGEN generates the
.cuttest artifact - the surrounding workflow decides how and where that artifact is used
- the overall setup is easier to integrate into modern tooling
With the MCP-based setup, the solution has now become more flexible and more practical for real usage. The focus is no longer on manually running scripts, but on providing a cleaner generation service that fits into a broader development workflow.
Why Copybook Expansion Became Important
One topic we did not cover in enough detail in the first version was copybook expansion. That became important very quickly once we started working with more realistic COBOL programs.
In many enterprise applications, the source file alone is not enough. Important structures are often defined in copybooks. If those definitions are missing, the generated tests can easily become incomplete or unreliable.
To address this in CutGEN, we now expand copybooks when they are provided by the user and then generate the unit tests based on the expanded source. This gives the generator the complete structure it needs and allows CutGEN to produce more complete and meaningful test cases.
Without that step, the generated tests would not always reflect the real layout of the program.
A Practical Challenge with COBOL Check
While working on this, we also encountered an issue in COBOL Check.
The problem was not in the generation itself, but in how fields coming from copybooks were interpreted later in the test flow. Since copybooks are normally handled by the COBOL compiler at runtime, COBOL Check did not have the same structural understanding on its own. As a result, fields defined in copybooks were effectively being treated as alphanumeric, even when their actual definitions were more specific.
This became especially relevant for programs where copybooks define important data structures in areas such as WORKING-STORAGE.
So while copybook expansion solved the context problem for CutGEN and improved the quality of generated test cases, it also exposed a limitation in the downstream testing toolchain.
What We Changed
First, in CutGEN, we improved the workflow so that user-provided copybooks are expanded before test generation. This gives the generator the full structural context it needs and allows it to produce more complete and more reliable .cut test cases.
Second, we went a step further and looked at the downstream issue in COBOL Check itself. During that analysis, it became clear that fields originating from copybooks were not being interpreted with the level of structural detail needed for this scenario. In practice, this meant that copybook-defined fields could end up being treated too generically, which limited support for realistic enterprise programs.
Rather than accepting that as a tool limitation or keeping a private workaround in our own environment, we decided to improve COBOL Check itself. We implemented the required changes and contributed them back to the project through a pull request that is currently waiting for approval from the project author.
For us, this is an important part of the story. CutGEN is not only about generating test files with AI. It also reflects a broader engineering approach: if a limitation in the surrounding toolchain stands in the way of practical adoption, we do not just work around it, we try to improve the ecosystem as well.
Why This Matters
This evolution makes CutGEN much more practical for real enterprise COBOL development. CutGEN has evolved from an early script-based prototype into a more practical MCP-based solution for generating .cut files, and along the way copybook expansion turned out to be an important requirement for real-world COBOL programs. It also helped us identify an improvement area in COBOL Check.
That is where this update becomes relevant:
- CutGEN can work with expanded copybook content to generate more complete
.cutfiles - the generation flow is now cleaner and easier to integrate through MCP
- the lessons from this work are also helping improve the COBOL testing ecosystem itself
Interested in trying out CutGEN? Feel free to reach out to us.
