Unit Testing ILE ProceduresHow 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).

OverviewHow 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

Requirements

Analysis

Design

Coding Unit Test

IntegrationTest

SystemTest

AcceptanceTest

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

Procedures can be shared with many applications. Unit Test Scripts capitalize on this ability.

Module To Be Tested

Procedure

Test ScriptMain

Test Script Support Module

UnitTest

Starting Unit Test Scripts

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.

For our example test script, we will test this procedure.

Write the test script as a program, making calls to the procedure to be tested and to the UnitTest procedures.

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

Each procedure tested will require its prototype to be added to the test program.

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.

Writing the Test Script - Start

Formatting the Output

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.

Example 1

Formatting the Output

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.

Example 1

Formatting the Output

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.

Example 2

Formatting the Output

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

Example 2

Formatting the Output

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.

Example 3

Formatting the Output

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

Example 3

Formatting the Output

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

Example 4

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 ResultsResulting output from the four tests run by the test script.

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.

Reusing Unit Test Scripts

Note: Please see the slide Compiling For Production to see differences between compiling for unit test and compiling for production.

crtrpgmod yourLib/EPS9CKDR dbgview(*list) replace(*yes)

crtrpgmod yourLib/EPS9CKDR.T dbgview(*list) replace(*yes)

Create the module that contains the procedures to be tested. Replace EPS9CKDR with your module.

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.

Compiling the Test ScriptEnsure your library list includes the library that the UnitTest module is in.

crtpgm yourLib/EPS9CKDR.T module(EPS9CKDR.T EPS9CKDR QGPL/UNITTEST)

Call EPS9CKDR.TCall the test script program. When it completes you will have created the test script spool file. Look for QSYSPRT in your spoolfiles.

Running The Test Script Program

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

printTest

endTest

5

67

8

1

23

4

Compiling For Production

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)

We do not want to add test objects to the production environment.

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