-
Notifications
You must be signed in to change notification settings - Fork 32
Design Goals
Home -> Development Guide -> General Development Guide
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 (that is, not directly on the mainframe) and to enjoy the benefits of fine-grained "microtest"-driven development at the level of individual Cobol paragraphs. Improvements you make to the code should either (a) enhance the product's ability to meet that goal, or at least (b) not degrade the product's ability to meet the goal.
- 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.
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.
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 a procedural language. Experience has also 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 Cobol-like syntax and save test suites in the form of Cobol copybooks. They need no other tooling and no other work to create and maintain test suites.
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.