Unit Testing ILE Procedures

How to Produce Reports of

Your Unit Test Results

Author: Greg Helton Countrywide Home Loans email: ghelton@countrywide.com

The three most expensive
programming errors ever made cost
$1.6 billion, $900 million and $245
million. Each error was caused by a
change to a previously correct
program
(Weinberg. Infosystems, August
1983).
 Overview
How do we test our code today?
The usual strategy is to create input data to represent
test scenarios and to verify the results after running the
program. This strategy:
• requires one or more fully functioning programs in
order to run the first test.
• incurs the overhead of creating records in multiple
files.
The results of these tests
• indicate problems but do not identify their source.
• generally are less than optimum, leaving some
code untested.
 Overview (continued)

Unit Testing ILE Procedures allows you to

• identify bugs more precisely
• test code as soon as it is written
This presentation will show you how you can create a test
script, compile it and link it to your module and produce a
printout of you procedure’s inputs, expected results and
actual test results. This script is RPG source code that once
written may be saved and reused at any later date.
 Terminology
 Acceptance Test - A specified level of testing in which all
aspects of the product are thoroughly and systematically
verified by the user and/or system owner that the product
performs as expected.
 Black Box Testing - An approach to testing that examines
product function based on requirements or specification and
not on knowledge of the implementation of the program it is an
external view of the system.
 End-to-End Test – system test; testing across applications
from the inception to the destruction of the objects.
 Integration Testing - An orderly progression of testing in
which software and/or hardware elements are combined and
tested until the entire system has been combined.
 Process Test - The Integration/System tests that are run on the
entire process.
 Terminology (continued)
 Regression Test - the process of validating modified parts of
the software and ensuring that no new errors are introduced
into previously tested code.
 Testing – a process performed at the end of a failing project
or, alternatively, a process performed in all stages of a
successful project.
 Unit Test Level - The first verification of new or changed
device in the process to determine if all new or modified
devices function correctly. This is generally the white box
testing of the module or device, but not their calls (using stubs,
instead). New or changed data conversion or bridge programs
should also be Unit Tested.
 White Box Testing – tests derived from the detailed design
with knowledge of the internal structure of the component.
 Make Testing Part of the Process

Acceptance
Requirements
Test

System
Analysis Test

Integration
Design
Test

Coding Unit Test

http://www.softwarearchitect.biz/chapter10/chapter10.htm
 Agenda
What is an ILE Procedure?
How Procedures Are Used by Unit Test Scripts
Starting a Unit Test Script
Writing the Test Script
Formatting the Output
Test Script Results
Reusing Unit Test Scripts
Compiling and Running the Test Script
Runtime Interactions Between Modules
Compiling For Production
Conclusion
 What is an ILE Procedure?

An ILE procedure is a discrete unit of work

providing a simple interface to a more complex
process. The simple interface allows the developer
to easily discern the purpose of the procedure and
the inputs and results.
These features of procedures not only simplify the
development and maintenance of code, they also
simplify testing.
How Procedures Are Used By Unit
Test Scripts
Test Module To Be Test Script
Script Tested Support Module
Main Procedure UnitTest

Procedures can be shared with many applications.

Unit Test Scripts capitalize on this ability.
 Starting Unit Test Scripts
For our example test script, we will test this procedure.

Note: you must use the

EXPORT keyword to export
your procedures in order to
perform unit tests using this
technique.
This allows other modules to
call the procedure. This is how
“sharing” is implemented.
Writing The
Test Script
Write the test script as a
program, making calls to the
procedure to be tested and to
the UnitTest procedures.

Each procedure tested will

require its prototype to be
added to the test program.

Four tests are run in this

script. Each produces the
printed results differently.
Each test will be explained
individually in slides to
come.
Writing the Test Script - Start
Include the copy Include the prototype for the The call to the startTest
statement for the procedure to be tested - procedure opens the printfile
UnitTest prototypes. YOUR procedure when you and places the text passed as
run a test script. a parameter in the print file
header.
 Formatting the Output
Example 1
The printed line shown here will be produced in the test results report spoolfile. The
printer file is defined in the UnitTest module and all printer file operations are coded
there.

Notice that the procedure name, the parameter, the expected result and the actual
result are shown. With these values you can determine if your procedure passed or
failed the unit test.
 Formatting the Output
Example 1
The printTest procedure requires four parameters.
Store the name of the procedure you are testing in the procName variable.
Set inputValue equal to the character values of the input parameters.
Set plannedResult to the character value of the value(s) you expect.
Obtain the procedure result(s) by calling it as shown on line 22. If the results are
numeric, convert to character using the built-in function %char (see line 23).
Call the printTest procedure passing the parameters in the order shown.
 Formatting the Output
Example 2

The format of this line is similar but, it is produced a little differently. The next slide
will show a more convenient way to produce this format.
 Formatting the Output
Example 2
The printTest procedure will accept literals for the first three parameters.
You can pass literal values for procedure name, input value(s) and planned
result. Instead of coding seven lines to print a unit test, we can get the same
result coding only four lines!
Literal values won’t work as the actual result - that would be cheating!
Call your procedure passing the input value, convert the output if necessary
and pass actualResult as the fourth parameter. (Lines 29 - 32.)
 Formatting the Output
Example 3

Calling the procedure “printFormattedTest” prints elements of the unit test

in four lines on the report. This gives you more room to print more or
longer parameters. It may make viewing the Test Scripts report easier.
 Formatting the Output
Example 3

Append one or more argument(s) to the argument list by calling

appendArgument.
Append one or more expected result(s) by calling appendExpectedResult.
Append actual results by calling appendActualResult.
Call printFormattedTest passing only the name of your procedure. (Lines
37 - 41.)
 Formatting the Output
Example 4

printFormattedTest can also be called with four parameters and omitting the use of
the append… functions. Literals may be used for the procedure name, input value(s)
and expected result(s).
 Writing the Test Script - Finish

End your test script by closing the print file with a call to endTest. Then set on
indicator LR and return.
 Test Script Results
Resulting output from the four tests run by the test script.
 Reusing Unit Test Scripts

Save your test script so it can be reused in

future tests. You and your team should agree
on a naming convention for your test scripts so
that they may be identified when needed.
The name of the module being test is
EPS9CKDR. The test script was saved as
EPS9CKDR.T, the name of the module to be
tested with “dot T” appended.
The “dot T” is one convention for telling
everyone that this is a test script source
member. Your team may want to use another
convention.
 Compiling the Test Script
Ensure your library list
includes the library that the
UnitTest module is in.

Create the module that

contains the procedures to be
tested. Replace EPS9CKDR crtrpgmod yourLib/EPS9CKDR dbgview(*list) replace(*yes)
with your module.

Create the test script module.

Replace EPS9CKDR.T with
the name of your test script
module. crtrpgmod yourLib/EPS9CKDR.T dbgview(*list) replace(*yes)

Create the test script

program. Be sure to include crtpgm yourLib/EPS9CKDR.T
at least three modules - list module(EPS9CKDR.T EPS9CKDR QGPL/UNITTEST)
the test script first followed
by the module to be tested
and then UnitTest.
Note: Please see the slide Compiling For Production to see differences
between compiling for unit test and compiling for production.
Running The Test Script Program

Call the test script program.

When it completes you will Call EPS9CKDR.T
have created the test script
spool file. Look for QSYSPRT
in your spoolfiles.
 Runtime Interactions Between
Modules
Module To Be Tested Test Script Test Script Support
EPS9CKDR EPS9CKDR.T Module

UNITTEST
callp startTest 1
startTest
2
3
getCheckDigit result = getCheckDigit(100)
4
5
callp printTest printTest
6
7
callp endTest endTest
8
 Compiling For Production
We do not want to add test
objects to the production
environment.

1. Do not include modules

CRTRPGMOD MODULE(YourLib/YourModule)
or programs created from
SRCFILE(QRPGLESRC)
the test script on your
Turnover form.
2. Do not include the CRTPGM PGM(YourLib/YourModule)
MODULE(YourModule)
UnitTest module on your
Turnover form.
3. In the Turnover program
creation instructions, do not
bind your program to the
UnitTest module or to your
test script module.
 Conclusion
With Unit Test Scripts you can also:
• Reduce project risk by scheduling complex components
for construction and testing early in the project. You no
longer require a complete system in order to begin testing.
• Test emergency fixes quickly to ensure the fix hasn’t
broken other functionality.
• Reduce the cost of subsequent modification by analyzing
Test Scripts to determine procedure functionality.
If you create software in a component style using ILE
procedures you will have software that is has a high level of
Quality Assurance, is easily retested and produces
documented test results.