-
Notifications
You must be signed in to change notification settings - Fork 32
Design Goals
Home -> 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.
'Nuff said.
We want the tool to be intuitive for Cobol programmers. Therefore, the syntax for test cases and test suites is designed to be Cobol-like or Cobol-ish. When you make enhancements that include changes to the test syntax, please keep this objective in mind. In particular, don't assume the target audience will be familiar with tools like JUnit, Rspec, or Jasmine. Also be alert to possible collisions with Cobol reserved words.
Within reason, try to maintain backward compatibility from the perspective of programmers who have been using the proof of concept project.
However, if it is necessary to deviate from the existing design to achieve practical goals, then do so with appropriate backward compatibility and documentation; the existing user base is small, and there is no need to compromise future users to retain behavior that is only used by a few people.
Please feel free to add issues for desired features, bug fixes, general design improvement, platform-specific problems, and aspects of particular versions or "flavors" of Cobol that the project is not handling properly.
Please add or modify test cases as appropriate for the changes you make. Whether you do this in a test-first fashion is your choice. The first thing we will do is merge your changes and run the test suite as-is. If any test case fails, the changes will be reverted.
It is also important to keep the documentation in sync with any changes you make. Please update the documentation (this wiki, for now) to reflect the changes you make to the code. This will be part of the pull request review. Don't worry about writing perfect English. Accurate content is the important thing. We can tweak the English if necessary.
It is a design goal of the project that the code should work on Unix, Linux, Windows, and zOS, and if possible OS X. Please keep this in mind when making changes to the code. This was the reason to choose Java as the programming language for the tool. It is a first-class citizen on all the target platforms.
In most large IT shops where mission-critical Cobol applications exist, multiple versions of Cobol are in production. Please do not "break" functionality for one version of Cobol in the process of adding support for another version. We need to support Cobol as it is found "in the wild."
There are many options for Cobol programmers with respect to the appearance of source code. For instance, some prefer the period-per-sentence style and others the period-free style. Some prefer all caps, some lower case, and some mixed case. Some like to number their paragraphs and others don't. Some write nested programs and others prefer subprograms. Some make extensive use of Procedure Division copybooks to achieve source-level code reuse. Because of the purpose of this project, we have to be style-agnostic. Our individual preferences are not important. The tool must support any and all styles of Cobol coding.