Test-Driven Development and Unit Testing for Cobol on Mainframe

Learn to apply unit testing and Test-Driven Development (TDD) in Cobol on z/OS, explore tooling differences, and gain hands-on TDD experience to enhance testing and software design skills.

The course has approximately 40% presentation and 60% hands-on exercises.

This course can be done using our z/OS labs, but results will be better if done using the client's z/OS system.

• Cobol z/OS programmers who need to test applications effectively at the unit level.
• Cobol z/OS programmers who want to use Test-Driven Development (TDD) in developing new applications and/or making enhancements to existing applications.
• Programmers/software engineers coming to the z/OS environment with previous experience in languages for which unit testing and TDD are established practices, and who want to bring those practices forward in their new role.

• Working knowledge of software testing basics at the level of Course: Software Testing Basics for Programmers.
• Prerequisite can be established by:
  • Taking the following Course: Software Testing Basics for Programmers
  • Passing the assessment test for Course: Software Testing Basics for Programmers
  • Equivalent industry experience

• Understand different levels of testing and what is meant by a "unit" of code
• Understand how TDD functions as a software design technique and how it supports automated testing
• Understand how tooling, assumptions, expectations, and culture differ between mainframe and distributed environments
• Understand how to achieve unit-level executable tests in Cobol without any additional tooling
• Understand how to use the COBOL Check open-source project to support unit-level executable tests in COBOL
• Understand how "refactoring" differs from general "changes" to code
• Understand the purpose and mechanics of the TDD cycle (Red-Green-Refactor)
• Gain basic hands-on experience with TDD

• Differences between the mainframe environment and other environments with respect to TDD and testing
• Tooling
  • Editors and Integrated Development Environments
    • Mainframe:
      • Focus on connectivity and sensible transfer of code and JCL to/from z/OS; automatic conversion between PDSs / MVS data sets and "standard" filesystems; smart handling of ASCII/EBCDIC translation; integration with (or simulation of) ISPF and File Manager functionality.
      • Tools are designed around the assumption that people will maintain a live connection with z/OS while working on their local IDE; their local system is a glorified 3270 terminal.
    • Distributed:
      • Focus on rapid coding and testing; unit test frameworks, refactoring support, profilers, debuggers, integration with test servers, integration with version control systems.
      • Tools are not designed with the expectation programmers/testers will be connected to the target deployment environment while working locally.
  • Unit testing frameworks
    • Mainframe:
      • Most tools can exercise a complete Program Object or Load Module, but nothing smaller
    • Distributed:
      • Fine-grained unit testing tools can work with individual functions/methods
• Focus of improvement 2000-present
  • Mainframe: Stability, security, performance, capacity, data analytics
    • Result: Huge improvement on the operations side; limited progress in tools for programming and testing
    • General lack of awareness of contemporary software development methods
  • Distributed: Rapid delivery of new features, "delight the customer"
    • Result: Huge selection of robust tools for programming and testing; limited progress in support for stable, secure production operations
    • Wide use of team-centric, collaborative software development methods
• Code habitability
  • Mainframe: Legacy applications have been refined over many years by highly skilled people dedicated to the platform and its languages; code bases tend to be "clean", except those inherited from former third-party vendors
  • Distributed: The emphasis on rapid delivery of features combined with exponential growth in the number of new programmers entering the labor force for the past 25 years has resulted in many very messy code bases that are nearly impossible to work with; this is the reason for the strong emphasis on tools and techniques to refactor messy code and surround it with unit tests.
• Technical differences
  • Unit testing and TDD emerged from the Object-Oriented design world; most tools and methods assume OO languages will be used, and many cannot be described without recourse to OO terminology.
  • Traditional mainframe language compilers and runtimes (COBOL, PL/I, REXX, Assembler) were not designed to enable instrumentation of object code to support testing; units of code smaller than a complete Program Object or Load Module can't be isolated and executed separately from a main program (except by playing "games" such as COBOL Check does).
• Unit tests or microtests (general)
  • Definition of "unit"
  • Unit testing COBOL code
    • Hand-rolled unit tests - include test code in program source, toggle on/off
    • COBOL Check open source project
      • COBOL Check - batch main program
      • COBOL Check - batch subprogram
      • COBOL Check - CICS program (planned functionality)
      • Running COBOL Check as part of a CI/CD pipeline
      • Integrating COBOL Check with VSCode (if applicable)
      • Using COBOL Check offline to support z/OS applications (Linux or Windows)
• Test-Driven Development (TDD)
  • Hype and "religious" opinions about TDD
  • Why TDD has not been used historically on the mainframe platform
  • Benefits and effects of TDD
  • Basic mechanics of TDD (the Red-Green-Refactor cycle)
  • Using TDD for greenfield COBOL development
  • Working with existing code bases
    • Characterization tests
      • Characterization tests (general)
      • Characterization tests for batch COBOL applications
      • Characterization tests for CICS applications
    • Refactoring to isolate code units to enable automated functional checks
      • When is refactoring useful?
      • When is refactoring not useful?
      • How do you judge when to stop refactoring?
      • Simple refactorings to isolate small units of COBOL code
      • Tools (or the lack thereof) to support refactoring
• Beyond unit testing
  • Component tests (general)
    • Testing single batch programs using standard z/OS facilities
    • Testing single batch programs using IBM zUnit
    • Isolating CICS programs for testing
      • Approach #1 - LINK to the program under test from a purpose-written test driver
      • Approach #2 - write an XEIIN global exit to suppress selected CICS commands; significant development effort to implement for flexibility in the longer term. (This will not be done hands-on during the course.)
  • End-to-end testing
    • Automate testing (checking) a complete batch job
    • Automate testing (checking) a CICS transaction involving multiple LUWs. (This will not be done hands-on during the course.)