|
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. > >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.