®

IBM Software Group

zUnit – Technical Deep DiveADFz/IDz/RDz

January 15th, 2019

Jon Sayles / IBM - jsayles@us.ibm.com

DevOps

2

IBM Trademarks and Copyrights

© Copyright IBM Corporation 2016, 2017, 2018, 2019. All rights reserved.

The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates.

This information is based on current IBM product plans and strategy, which are subject to change by IBM without notice. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way.

IBM, the IBM logo, the on-demand business logo, Rational, the Rational logo, and other IBM Rational products and services are trademarks or registered trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

3

UNIT zUnit Testing with IDz▪ zUnit Terms, Vocabulary, Application Support

▪ zUnit Development Process and Run-Time Architecture

▪ Test Case Editor

▪ Five Scenarios:

1. Subroutines (White Box Testing)

2. Data capture for Test Case input

3. Standalone Batch (Black Box Testing)

4. Importing Data and Stubbing Modules

5. DB2 Programs

▪ zUnit Setup and Configuration: Overview▪ Install/Configure

▪ zUnit PROCs

▪ zUnit Property Group configuration

▪ zUnit XML Libraries

▪ zUnit Technical Training

Today’s Topics

4

What is Unit Testing?Unit Testing is a software testing method by which individual units of source code (sets of one or more computer program modules together with associated control data, and operating procedures) are tested to determine if they are fit for use. Unit testing verifies code according to design specifications – and uncovers application vulnerabilities. . Wikipedia

IDz provides two approaches to Unit Test:1. White Box Testing – aka “Glass Box” Testing:

• Testing to ensure/validate the internal logic and the interfaces of a software application

• Java: Methods

• Enterprise Application: COBOL Subroutines …and… PL/I External Procedures

2. Black Box Testing

• Traditional Enterprise Application testing approach, that examines data changed by running a load module:

• Batch

• Online

5

White Box testing

White-box (Glass-box) testing verifies code according to design specifications and uncovers application vulnerabilities – making them visible to the testers.

An individual unit of software is an isolated logic construct or routine within a call-able program:

• Date validation

• Credit Card number look-up

• Tax computation

• Healthcare Co-pay calculation

With zUnit, White Box testing is done at the “Compilation Unit” level – which is:

• A single program

• Plus all its copybooks – necessary for a clean compile

Compilation Unit == Subroutine

6

zUnit Black Box testing is available for QSAM & VSAM files.

Black Box testing is done against a Compilation Unit.

Black Box testingBlack Box Testing examines the I/O outcomes of an application (what the program produces as output data) without regard to program code (how the program does what it does)

7

Unit Testing Subroutines

Using zUnit you Analyze/Customize LINKAGE SECTION values, then Build and Run the Unit Test• Customized input LINKAGE values test specific functionality within the subroutine

• Output LINKAGE data are compared against defined/expected returned values from the subroutine

• If the expected values match the returned values the test passes. If not the test fails

zUnit subroutine testing allows you to validate specific application functionality as opposed to program file outputs.

During Unit Test your module is run with defined input values.

The subroutine’s zUnit run produces LINKAGE SECTION output values which are compared against the defined expected output values.

The results of these comparisons dictates Unit Test pass/fail return codes.

Man

ipu

late

8

9

JES

zUnit Run-time Architecture

zUnit Test RunnerDoes the following:

READ AZUCFG(MEMBER)

CALL (invoke) Test Case Which invokes each Test Case Entry

Which interacts with your program’s logic

The generated code:- Sets up unit test variable values - Runs the subprogram

- Evaluates the Assertion outcome- Releases system resources

WRITE AZURES(MEMBER)

//AZUCFG DD DSN=…

• Names the Test Case module(s)

//AZURES DD DSN=…• Stores test results in XML PDS member

//… EXEC PGM=Test Runner//AZUCFG Test Suite PDS//AZURES Test Result PDS//AZULOD Load LibrarySchedules/Launches…

Submit JCL…

Test Case(PDSE)

Load Module to be unit tested

• Verifiable logic routine• Modify LINKAGE SECTION values

during program execution

For each assertion:- Assign Linkage Variables to Assertion values- CALL subroutine using Assertion values- Evaluate outcome

- Did expected values return from subroutine?- Release resources

z/OS

Test Suite

Target SubroutineTest Results

GOBACK ENTRY

10

Current zUnit SupportPL/I or COBOL Subroutine compiled/Linked as a Load Module to a PDS or PDSE:

• COBOL v4, v5 and v6 supported

• Subroutines are Unit Tested through data values passed in LINKAGE

• Passed/Returned values (Assertions) are setup & evaluated by the Test Case

• QSAM/VSAM file I/O is supported in the subprograms

• Programs that contain SQL statements are supported

• But there currently is no support for comparing results of Embedded SQL statements

against expected returns for any SQL DML statement

• Assembler subroutines can be supported using a work-around that creates a COBOL wrapper program for the Assembler Call interface

• Stubbing out called programs is supported

• Saving/Externalizing Test Assertion values is supported

Support for zUnit testing of COBOL “main” or standalone file processing programs is available as of IDz v14

• File I/O “Black Box update testing” of QSAM and VSAM data sources

• SUPERC dataset comparison is generated by zUnit

11

Additional zUnit v14.x.x Features• Support for VSAM File I/O and VSAM Test Data Wizard - data file Import

• Previously only supported for QSAM files

• VSAM is not supported for PL/I programs

• Support for adding non-numeric data to numeric fields

• Previously type-checking was done during edit, and only valid numerics were allowed into PIC 9 fields

• Now you can dynamically redefine the data for the Test Case, and enter alphabetic values & garbage

• Support for One-Click Generate Test Case Run for DB2 programs

• Previously DB2 program run had to be run standalone Test Case (the were not part of the wizard cycle)

• Debugging:

• Show test target source first. Test case failures documented with record and field names in SYSPRINT

• Allocate JCL – sample JCL that is used to create the zUnit configuration datasets by running a single batch job

• Recorded runtime data now can be imported from z/OS Debugger to Test Data Entry for unit testing purpose.

• In existing zUnit features, local Enterprise COBOL and Enterprise PL/I sources are supported in scenarios of open source configuration management.

• zUnit identifies a return value parameter of a PL/I Function CALL type sub programs. You can see the return value in the Test Entry Data Editor.

12

Discussion: Why Unit Test?

By testing individual logic routines in your programs:

• You can move through the lifecycle more quickly, because you have precise feedback about separate logic routines

• So you can better understand cause & effect

• And you know that your code works and you know how your code works, which gives you confidence to make enhancements and modifications

• Because you execute zUnit Tests through JCL:

• The testing can be automated

• The end-to-end process takes less time than interactive debugging.

• And it can be more systematic

• Unit Testing allows you to understand “cause & effect” in your program logic – and brings you much closer to your code

All of the above benefits allow you to catch errors earlier in the lifecycle…

13

The value of early lifecycle testing

During the Coding orUnit Testingphases

$80/defect

During the BUILD phase

$240/defect

During Quality Assurance or the System Test phases

$960/defect

Once releasedinto production

$7,600/defect+

Law suits, loss of customer trust,

damage to brand

“80% of development costs are spent identifying and correcting defects” **

**National Institute of Standards & Technology

Source: GBS Industry standard study

Defect cost derived in assuming it takes 8 hours to find, fix and repair a defect when found in code and unit test. Defect FFR cost for other phases calculated by using the multiplier on a blended rate of $80/hr.

14

Unit Testing is Not a “Silver Bullet”

GUI

3270

Regression

Testing

Performance

Testing

Interactive Testing

Integration Testing

Automated Unit Testing

Test Driven Development

Rational Function Tester

Application Performance Analyzer

zUnit

IDz Integrated Debugger

IBM Debug Tool

IBM recognizes this - and provides multiple testing solutions, each

optimized for different problem areas within the software testing

space:

15

16

Runtime(Batch Execution Flow)

Emulates standard batch program testing – but provides ability to customize Input / Output file values. Evaluates Unit Test results, based on expected...vs... produced data records

zUnit Test Runner

Run Test Case:• Input - Output File DSNs part of

generated Test Case code

…

Evaluate Test Results• Test Case code calls SuperC File

Compare – passing DSN for expected results

• This file is compared to the output data records created by the Test Run

z/OSInput DSN(s) and/or

Record Values

Output Dataset(s)

Produced by Batch

Program

Execute Batch PGM

RunBatch

Program

Evaluate SuperC

File Compare

Unit TestSuperC

File Compare

Expected Output

DSN(s)

Execute ISRSUPC

1.2.

3.4.

Black Box Unit Testing – Standalone Batch Programs

17

18

• IDz Client installation:• Version: We recommend v14.1.3 or later

• Plug-ins: No particular functionality is required above whatever you’ve decided to use. However we do recommend IBM Data Studio

• Workspace: You can utilize your existing Workspace(s). However, we recommend that the Workspaces be created new, at the Client release level. And whatever Workspace you choose will need to import the Property Group files

• Property Group files: Upcoming slide on customization.

• IDz Server installation:• Version: We recommend v14.1.3 or later

• Performance: A stress test should be deployed before production App-Dev use by your developers

• Client connectivity: Stability across all functions. And 100% configured/working functionality:

• Also, please look specifically at Allocate Like, which exercises the ISPF Gateway

integration/config.

• Source Management: This course works from COBOL programs in TSO Libraries. If you wish to integrate Endevor, Changeman, etc. you will need to work thru workflow & functionality independently from the workshops & materials in this doc

• IDz Installed PROCs: See next slides. DSNs in the PROCs must be resolved to the names of specific system Libraries in use at your shop (COBOL compiler, CICS, DB2, IMS and IDz Runtime Libraries)

IDz Product Setup

19

zUnit/IDz Property GroupszUnit dynamically generates, builds & runs Test Cases – on your LPAR It can accomplish this only by means using custom entries to your Property Group and PROCs

• JCL

• JOB Card that can be submitted & run in your LPAR

• Other JOB statements: //JOBLIB, JCLLIB, etc.

• COBOL:

• SYSLIB

• Language/Compile libraries

• Compile PARMs

• BIND statement – if DB2

• Link Edit:

• Load Libraries & Lib-path

• Link Edit specific PARMs

• IDz libraries

• zunit:

• AZU… XML libraries

• Generated code

• Generated Stub Records

IDz Property Group entries rely on the customization of PROCs installed with the IDz server…

20

Because zUnit dynamically Generates, Builds & Runs Test Cases the IDz server infrastructure must be configured/customized correctly by your Systems Programmers – including references to IDz System PROCs, IDz Runtime Libraries, your Property Group(s) and your standard Build Runtime Libraries

IDz/ADFz

PROCsELAXFCOC

ELAXFLNK

ELAXFGO

AZUZUNIT

AZUZDB2

Standard

IBM Build

RuntimesCOBOL, PL/I, DB2

IDz/ADFz

Runtime

Libraries

Property

Groups

JCL tab points to PROCLIB

COBOL tab selects ELAXFCOC

Link tab selects ELAXFLNK

zUnit tab selects AZUZUNIT

zUnit tab selects AZUZDB2

Installed IDz PROCs

Property Groups/PROCs/IBM Runtimes – Big Picture

21

Allocate AZUxxx – XML Libraries

The AZUxxx libraries are z/OS XML PDSs referenced in the zUnit tab of the Property Group file

This PDSs will contain zUnit generated artifacts

Use your TSO ID as the high-level qualifier:

1. The AZU* libraries have the following DCB:

• LRECL: 16383

• BLKSIZE: 32760

• RECFM: VBA

• Library Type: PDSE

2. GEN.COBOL is where the generated Test

Cases reside

3. LOAD (for the Test Case) is a PDSE format

Load Library

4. LISTING is: FBA/LRECL: 133

5. SYSDEBUG is: FB/LRECL: 1024

22

Topic

s

zUnit Hands-on Training Course

▪ zUnit Terms, Vocabulary, Language Support

▪ zUnit Development Process and Run-Time Architecture

▪ XML Editor Options

▪ QSAM Data Import

▪ Working with DB2 Programs

▪ Stubbing out Program Calls

▪ Debugging your Test Case

▪ Analyzing Programs for Unit Testing “Fit”

▪ Workshop/Lab Instructions - Appendix

Offered 2-3 times/per year• Watch for announcement in IDz Newsletters

Prerequisites for attending:• Two+ years of production z/OS application development• Formal IDz training and 6+ months of IDz usage• Installed IDz Client software • Access to IDz Server at version IDz v14.1.1 or higher

23

Backup Slides

24

Review - xUnit Vocabulary / zUnit Implementation

▪Test Execution: JCL that invokes the Test Runner (a “supervisor program” or “test harness” that runs your Test Suite)

▪Test Runner: The zUnit “supervisor program” invoked by Test Execution, that:

▪ Reads a Test Configuration Test Suite

▪ Calls your Test Cases

▪Test Suite: an XML configuration file that defines which Test Cases the Test Runner should execute (Note - a Test Case == a Load Module)

▪Test Case: An RDz-generated COBOL or PL/I program that:

▪ Is called by the Test Runner

▪ Uses a Test Fixture to Call your Subroutine and write test outcomes to a Test Results file

▪Test Fixture: A set of generated programs nested inside your Test Case. Test Fixturesrun Tests that utilize Assertion logic to Call your Subroutine, and evaluate the result.

▪Subroutine: The target call-able program to be Unit Tested

▪Test Results: An output dataset that describes the results of each test run in xUnit standard (XML) file format

▪Assertion: A simple pass/fail predicate used to test one part of your Subroutine’s logic

** Test Execution, Test Runner, Test Suite, Test Case, Test Fixture, Assertion == xUnit vocabulary

25

Links - to additional Unit Testing content

https://developer.ibm.com/mainframe/2016/01/25/getting-started-with-rdz-zUnit-part-1-olivieribm/

Getting Started With zUnit Part I - Technical Blog

https://developer.ibm.com/mainframe/2016/05/23/getting-started-with-rdz-zunit-part-2-olivieribm/

Getting Started With zUnit Part II - Technical Blog

https://developer.ibm.com/tv/zunit-unit-testing-with-rdz-v14/?cm_sp=dw-dwtv-_-rdz2016-_-unit-testing-with-dz-idz-v14

zUnit for zOS Unit Testing - Video

https://www.ibm.com/developerworks/community/files/app/file/72769948-1838-4eca-93c6-348d84c424b0

zUnit for zOS Unit Testing - Class - Enablement PDF

https://developer.ibm.com/mainframe/2018/06/27/new-shift-left-testing-features-ibm-developer-z-systems-v14-1-3/

What’s new in zUnit v14

26

Demonstration ProgramsFive scenarios:• EBUD00: Simple subroutine

• EBUD01: Generated test data

• MSTFILUP: Standalone batch

• PHONEC1: DB2

• PERFCALC: Stub modules