Unit Testing ILE Procedures

1
Unit Testing ILE Procedures

• How to Produce Reports of Your Unit Test Results

Author Greg Helton Countrywide Home Loans
email ghelton_at_countrywide.com
2
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).
3
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.

4
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
  procedures 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.

5
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.

6
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.

7
Make Testing Part of the Process
Requirements
AcceptanceTest
SystemTest
Analysis
IntegrationTest
Design
Coding
Unit Test
http//www.softwarearchitect.biz/chapter10/chapter
10.htm
8
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
9
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.
10
How Procedures Are Used By Unit Test Scripts
Test Script Support Module UnitTest
Module To Be Tested Procedure
Test Script Main
Procedures can be shared with many applications.
Unit Test Scripts capitalize on this ability.
11
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.
12
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.
13
Writing the Test Script - Start
Include the copy statement for the UnitTest
prototypes.
Include the prototype for the procedure to be
tested - YOUR procedure when you run a test
script.
The call to the startTest procedure opens the
printfile and places the text passed as a
parameter in the print file header.
14
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.
15
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.
16
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.
17
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 wont
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.)
18
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.
19
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.)
20
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).
21
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.
22
Test Script Results
Resulting output from the four tests run by the
test script.
23
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.
24
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 with your module.
crtrpgmod yourLib/EPS9CKDR dbgview(list)
replace(yes) crtrpgmod
yourLib/EPS9CKDR.T dbgview(list) replace(yes)

Create the test script module. Replace EPS9CKDR.T
with the name of your test script module.
Create the test script program. Be sure to
include at least three modules - list the test
script first followed by the module to be tested
and then UnitTest.
crtpgm yourLib/EPS9CKDR.T module(EPS9CKDR.T
EPS9CKDR QGPL/UNITTEST)
Note Please see the slide Compiling For
Production to see differences between compiling
for unit test and compiling for production.
25
Running The Test Script Program
Call the test script program. When it completes
you will have created the test script spool file.
Look for QSYSPRT in your spoolfiles.
Call EPS9CKDR.T
26
Runtime Interactions Between Modules
Module To Be Tested EPS9CKDR
getCheckDigit
Test Script EPS9CKDR.T callp
startTest result getCheckDigit(100) callp
printTest callp endTest
Test Script Support Module UNITTEST startTest p
rintTest endTest
1 2
3 4
5 6
7 8
27
Compiling For Production
We do not want to add test objects to the
production environment.
1. Do not include modules or programs created
from the test script on your Turnover form. 2.
Do not include the 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.
CRTRPGMOD MODULE(YourLib/YourModule)
SRCFILE(QRPGLESRC)
CRTPGM PGM(YourLib/YourModule) MODULE(YourModule)
28
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
  hasnt 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.