The daily edition.

Scope and Overview

This article covers command-line execution, isolation models, and CI reporting in the Rocket Unit Testing Framework (MFUnit) for Rocket Enterprise Developer / Enterprise Server 12.0 on Linux/UNIX.

Modern continuous integration (CI) pipelines demand fast, automated regression testing for legacy and modernized COBOL applications. The Rocket Unit Testing Framework allows developers to write unit tests for native COBOL programs and mainframe batch/online logic. Beyond executing tests within the IDE, the framework provides a robust command-line runner (cobmfurun32 and cobmfurun64) designed for automated build systems, containerized test runners, and Jenkins CI servers.

Test Runner Architecture and Process Isolation

As detailed in Running Tests, test suites can be packaged as shared objects (.so), intermediate files (.int), generated files (.gnt), or XML/plain-text test fixture definitions (.mfu).

On Linux/UNIX, tests are invoked from the shell prompt using the native test runner executables documented in Test Runner Syntax Options:

• cobmfurun32 or cobmfurun64: Executes 32-bit or 64-bit procedural COBOL test suites.
• cobmfurun32_t or cobmfurun64_t: Appends _t to execute within the multi-threaded run-time system. Threaded runners are required whenever test cases configure execution timeout limits.

Multi-Process Fault Isolation

A critical operational capability of mfurun is its process model:

-process:{separate|single}

By default, the runner operates in separate process mode. In this mode, the parent test runner process forks an isolated worker process for each individual test case. If buggy application code under test suffers a fatal segmentation violation, divide-by-zero, or unhandled runtime abort, only the worker process terminates. The parent runner catches the exit signal, records the failure in the test report, and continues executing subsequent test cases.

Additionally, -isolate:true (the default) guarantees that working-storage and shared memory resources reset to their initial values between test cases.

CI Integration: Generating JUnit-Formatted Reports

By default, the test runner prints a high-level summary to standard output and generates a plain-text report (<testsuite>-report.txt). However, CI servers like Jenkins or GitLab require structured XML output.

As described in Example - Test Results JUnit Format, passing -report:junit generates JUnit-compliant XML reports for each test case:

cobmfurun64 -verbose -report:junit -junit-packname:com.enterprise.billing -outdir:./test-reports billing_tests.so

Key reporting parameters include:

• -report:junit: Produces XML test results named TEST-<package-name>-<test-case-name>.xml.
• -junit-packname:<package-name>: Organizes results under a Java/JUnit package hierarchy.
• -outdir:<directory>: Directs all generated .xml and text reports to a dedicated build artifact directory.

Jenkins CI Enhancements

When running inside Jenkins pipelines, detailed in Using the Results on a Jenkins CI Server, developers can pass:

cobmfurun64 -jenkins-ci:junit-attachments -diagnostics-color:jenkins billing_tests.so

• -jenkins-ci:junit-attachments: Integrates with the Jenkins JUnit Attachments Plugin, linking captured program dumps and console logs directly to failed test cases in the Jenkins UI.
• -diagnostics-color:jenkins: Embeds ANSI color sequences formatted specifically for the Jenkins AnsiColor plugin.

Selective Execution and Rapid Rerun Workflows

To optimize pipeline execution time, mfurun provides targeted filtering and rerun mechanisms:

1. Metadata Trait Filtering: Test cases can define custom tags in source code using the MFU-MD-TRAITS variable (or traits=<name> in .mfu fixture files). The runner can selectively execute subsets using -trait:<trait-names>:

``bash cobmfurun64 -trait:smoke,critical billing_tests.so ``

2. Automated Failure Reruns: In large test suites, developers can isolate failing tests using -generate-flist:<filename>. This exports the names of all failed test cases into a plain-text side file:

```bash # First run captures failures cobmfurun64 -generate-flist:failed_tests.txt billing_tests.so

# Subsequent run re-executes only the failed tests cobmfurun64 -testcase:@failed_tests.txt billing_tests.so ```

Operational Prerequisites and Nuances

• Timeout Threading Requirement: Never run tests with timeout attributes under non-threaded runners (cobmfurun32 / cobmfurun64); always specify the threaded variant (_t) so the runtime timer thread can interrupt long-running loops.
• Timer Resolution in Reports: While -high-res-timer:true enables microsecond performance counters for text reports, JUnit XML schemas do not support microsecond timestamps; standard millisecond timings are recorded in JUnit output.
• Return Code Propagation in CI: By default, mfurun returns a non-zero exit code upon test failure. When build systems rely on post-build test parsers rather than immediate shell step termination, -ignore-return-code:true can be supplied to allow subsequent pipeline stages to proceed.

Documentation Takeaway

In Rocket Enterprise Developer 12.0 for Linux/UNIX, the Rocket Unit Testing Framework provides resilient automated testing via separate-process fault isolation and threaded runners for timeout enforcement; build pipelines can standardize on -report:junit and -jenkins-ci for Jenkins integration, while leveraging -trait filters and -generate-flist to re-execute only failed test cases.