Re: Unit-testing service programs

I'm trying to test application logic, not the parameter passing logic.

My standard is to move any *NOPASS/*OMIT parameter into a working
storage data item.  If I accidentally refer to an unpassed parameter,
I'll get a soft application error (because the data value with be zero
or blank); I'd rather handle that than a MCHxxxx error.

I'm in the process of moving about 1,200 business rules into 100
service programs.  I'd like to be able to perform unit tests easily,
and regression testing requires repeating the test with the same data.
 I don't want to write and debug another 100 programs and commands
(but I may have to); if you're going to write a test-bed program, it
has to be production-quality.  The current solution uses CAX macros to
set values in STRDBG; setting up the script is overhead regardless of
the solution

Example: my intermodal application receives trailer and container
event information from steamship lines, railroads, and trucking
companies.  Every event passes through one service program; that
program adds event records to a transactions file and updates files
with updated statuses, dates, and times (that's the business logic). 
I'm supporting about 90 events, and not all events are required, and
some events arrive out of sequence (due to vendor reporting issues).

To test this service program, I set up a command, a stub RPG program,
and a CL script.  I added a dozen events (representing a typical
business transaction for a specific shipment) to the script file,
where each event was processed an execution of the command.  Each
execution of the command passed data to the service program through
the stub program; usually data would be passed by another application
program, such as an EDI routine.  I used SBMDBJOB to execute the
script file; all 12 events processed automatically and I reviewed the
results.

Going forward, I can repeat the test easily to see if I've fixed the
initial problem and not introduced any new ones (after reinitializing
the test data, of course).  Over a period of time, this specific test
script has grown much larger; it reflects a wide variety of imperfect
combinations of events (missing events, out-of-sequence events).

Because of the command interface, it's easy to enter a one-off
transaction; this allows easy function-level unit testing and
debugging.

The detailed testing tools we have now are excellent for programmer
use; I'm trying to figure out what I have to do to take testing to the
next level in this environment.  WDSCi seems like the right venue for
such a toolâ

Thanks,
Reeve



On Mon, 20 Dec 2004 16:53:03 -0500, Barbara Morris <bmorris@xxxxxxxxxx> wrote:
> Reeve wrote:
> >
> > Is there a better way to test service programs than building a HLL
> > wrapper program or REXX procedure?  I use OPTIONS(*NOPASS:*OMIT) in my
> > parameters lists, call the service program without any parameters, and
> > use Debug to change parameter list values.
> >
> 
> Could you expand on this a bit?  It sounds like you're making the call
> with no parameters, and then while debugging the called procedure,
> you're updating the (unpassed) parameters with some test values.
> 
> For parameters passed by value, changing the value of an unpassed
> parameter can lead to bizarre and unpredictable results, since you would
> be changing storage that something else might be using.
> 
> But I don't see how it would work at all for parameters passed by
> reference, I don't see how it would let you test your logic to detect
> unpassed and/or omitted parameters, so I think I've misunderstood what
> you're doing.
> 
> What's wrong with creating a test procedure for each procedure in your
> service program?  I think it would take less time to write the test
> procedure than to do one debugging session, and you would have something
> permanent to run whenever you make a change.
> 
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
>