Overview

The stored procedure test harness is a unit-testing tool for DB2 mainframe developers building stored procedures running in a Language Environment.
Developers can develop and unit-test their code in parallel with client web development, store and run repeatable tests, verify associated DB2 settings in all test environments, run tests in foreground or batch mode and choose whether to commit or rollback updates.
By removing the dependency on prior client web development and the need for a module-specific custom test harness, build elapsed time is reduced and testing quality is improved.
Network and software costs can be reduced, as mainframe developers do not require web software, UDB and network user accounts to test their software.
Testing quality is improved as all modules can be tested in a uniform manner through the test harness.

How stored procedures are used for Web development

A DB2 stored procedure is effectively a COBOL / C / REXX DB2 language environment subprogram, which receives and returns linkage parameters via DB2. No commits are performed by the program as the overall control of database integrity is handled by the web software (typically ASP / html) using DB2 connect.
An additional feature available to stored procedures is their ability to return ‘result sets’. These are lists of data returned from DB2 using DB2 cursors. These lists are then handled by the web software and deployed as drop down window lists etc. A Stored procedure can return more than one list to its caller.
A mainframe DB2 stored procedure can also access IMS databases and may not perform any access to DB2 tables – this is rather like an IMS program which sends IMS messages, but does not access databases via DL1.
The web front end controls all commits and rollbacks of updates, using the remote procedure call method via DB2 connect. A web module may call many stored procedures to access the data required to build a web page. This means that one web page can have a co-dependency on many mainframe programs before being tested, and a mainframe module may require other mainframe modules plus the web page to be developed before testing can be achieved.
Features

The stored procedure test harness is a simple to use product, which enables easy specification and selection of the required test environment.
The user interface is a series of ISPF panels. The user is presented with an initial panel to select the stored procedure, DB2 subsystem and schema.
Once these preferences are saved, the user is presented with a panel containing the input / output parameters, which interface with the stored procedure. After the input parameters have been keyed, or recalled from an existing test, the ‘enter’ key is pressed to run the stored procedure in foreground or batch mode. Any result sets returned by the stored procedure are then displayed (if the user has requested this), before returning to the input panel for the next test.

Productivity gains

As outlined above in the features section, the test harness frees the developer from concerns regarding prior web development. It also means that a one-off test program does not need to be created to call the new stored procedure, with manually coded parameters, test conditions and result set processing. The stored procedure test harness does all this automatically by accessing the DB2 catalogue and dynamically building the interface, and handling all columns returned by any result sets. As well as reducing testing effort, by using the test harness, the developer is verifying that the DB2 catalogue parameters have been defined correctly in all target test environments. Tests for similar programs can be copied into the testing library and between 5 – 10% reduction of build and test effort can be achieved.

Quality improvements

1 All test executions of the stored procedure are 100% in line with the DB2 catalogue definition. Differences between calling applications parameters and stored procedure definitions are recognised far earlier.
2 Tests can be quickly defined and executed and copied between similar stored procedures.
3 Program modifications can be quickly absorbed into the testing process due to the dynamic nature of the testing tool. A cyclical build – test – build approach can be adopted to develop programs, as the testing tool reflects immediate changes to the DB2 catalogue
4 As custom – written test harnesses are not required, coding is reduced, time is saved and mistakes are eliminated.
5 Testing errors introduced by client software, middle tier, UDB / DB2 connect and other network issues are eliminated as the testing tool resides and executes on the mainframe.

--
swilso1