In this blog I will introduce Early Development Testing for VS Code extension (EDT extension) and show how it works under the covers.

TAZ EDT VS code extension allows a COBOL developer to unit test a COBOL program in isolation without calls to the middleware such as DB2 or CICS. This means a developer can focus on testing the integral logic of the program and not worry about setting up the environment where the real program runs.

What is a unit test?

A unit test is a testing method that validate the smallest isolated unit of code. In EDT VS Code, a COBOL program would be the smallest testable unit of code. A single unit test executes 1 COBOL program. EDT VS Code allows a developer to assert a program at various points during the execution. We refer to these points as “test point” in your unit test. The extension will automatically find test points in your program.

How does Dynamic Test Engine run COBOL unit tests?

In this blog we’ll go over 3 components that make this happen. 

• ztest file
• zdata file
• Dynamic Test Engine host component 

Test file (.ztest extension): A test file is a YAML file that defines one or more unit tests for a single program under test. The test file (.ztest) is associated one-to-one with a test data file (.zdata). Test  file defines which points in the code user wants to assert and data that should be asserted.

Test data file (.zdata extension): The program data file. This is the data your program will be executed with when it runs as part of a unit test. To obtain test data, a user can record their program during runtime. The extension provides an option to record CICS, IMS, and Batch programs.

Dynamic Test Engine host component: Dynamic test component or DTE is part of z/OS Debugger. COBOL unit tests need to run on z/OS and Dynamic Test Engine is the component that runs unit tests. EDT unit tests do not need to be compiled. The extension uploads test data to z/OS and runs or “replays” the program with that data against any load library. All calls to external subsystems and other programs are stubbed out or mocked by the engine. This means you do not need to have CICS or DB2 running. If there are any file IO calls, those would also be stubbed out by the engine. 

How can I unit test negative/error scenarios?

To create good unit tests, you need a mixture of both, happy path test cases and error scenarios. In other words, unit tests need to provide full program code coverage. To test multiple paths, a developer would need to record data for the desired scenarios. Once you have recordings that have the right data, you can create unit tests with that data. Depending on how you record you could end up with 1 recording that has multiple entries for the same program or multiple recordings. 

Let’s look how this all comes together:

Right-click on a COBOL program, choose a recording and creates a unit test.

See test points that will be executed in the program with given data

Click on each test points and see data in more detail. Assertion and mock data can be modified:

Run tests with a standard VS Code UI

Read the official documentation page for full details.