Skip to content

Overall Design Goals

Jump to bottom
Dave Nicolette edited this page Jan 30, 2021 · 2 revisions

Home -> Developer Guide ->

Project purpose

The project is intended to support legacy Cobol application maintenance on IBM zSeries (mainframe) systems by enabling developers to work either on-platform (directly on the mainframe) or off-platform (on a Windows, Unix, Linux, or OS X instance not connected to a mainframe) and to enjoy the benefits of fine-grained "microtest"-driven development at the level of individual Cobol paragraphs.

General design goals

  • Support fine-grained automated unit testing of Cobol programs (individual paragraphs).
  • Enable test-driven development of Cobol code targeted to the zOS platform in isolation from the mainframe (for instance, on a laptop).
  • Ensure source-level compatibility across zOS, Unix, Linux, and Windows platforms.
  • Require no modification of production code to enable unit testing.
  • Enable developers to write tests in plain vanilla Cobol, or at worst to learn special statements that follow familiar Cobol conventions.
  • Support batch main programs.
  • Support CICS programs.
  • Support called subprograms.

Automated integration testing is out of scope

Possibly because the term unit lacks a standard definition, people often ask how the tool can support testing or checking at a scope larger than that of fine-grained microtests. To be clear, that is out of scope for this tool. Please see the wiki entry on Component and Integration Testing for more information.

Design approach

Other test frameworks for mainframe Cobol have been based on the xUnit architecture, as developed by Kent Beck starting with SUnit. It is a popular architecture for unit testing frameworks. However, experience has shown it to be counterintuitive for most mainframe Cobol developers, as it is based on object-oriented thinking to support object-oriented languages.

Despite supporting some object-oriented features in recent releases, Cobol is fundamentally a procedural language. Existing "legacy" applications, which account for nearly all Cobol code in the wild, are written in the procedural style.

Experience has shown that developers will set aside a tool they find cumbersome or confusing, as they want to focus their efforts on solving problems and not on wrangling tools.

With that in mind, cobol-check asks developers to write test cases in a Cobol-like syntax. They need no other tooling and no other work to create and maintain test suites. Test cases look similar to the following:

           TESTSUITE
           "Greeting includes the user name when it is provided"

           TESTCASE "When message type is greeting it returns Hello, James!"
           SET MESSAGE-IS-GREETING TO TRUE
           MOVE "James" TO WS-FRIEND
           PERFORM 2000-SPEAK
           EXPECT WS-GREETING TO BE "Hello, James!"

      * You can include Cobol-like comment lines, if you wish
           TESTCASE "When message type is farewell it returns Goodbye, James!"
           SET MESSAGE-IS-FAREWELL TO TRUE
           MOVE "James" TO WS-FRIEND
           PERFORM 2000-SPEAK
           EXPECT WS-FAREWELL TO BE "Goodbye, James!"

The tool emits output that looks like this:

TESTSUITE:
Greeting includes the user name when it is provided
     PASS:   1. When message type is greeting it returns Hello, James!                          
**** FAIL:   2. When message type is farewell it returns Goodbye, James!                        
    EXPECTED <Goodbye, James!>, WAS <See you later, James!>
 
  2 TEST CASES WERE EXECUTED
  1 PASSED
  1 FAILED

As Cobol was not designed to enable runtime instrumentation or probing, cobol-check merges a text file containing test cases with the original Cobol source file to produce a copy of the Cobol program that has the test code embedded in it. This program must be compiled and executed to run the test suite.

While many developers will question the value of testing a copy of a program instead of the actual program, we consider this a pragmatic workaround to enable fine-grained microtesting of individual Cobol paragraphs in isolation. The practical value of testing at this level of granularity outweighs the largely philosophical question of testing against a copy.

Clone this wiki locally