RE: Function Opinion -- RPG400-L

At 09:22 AM 10/16/03, you wrote:

I have a question about testing with this method. In our shop, if I have multiple procedures in a single source member that compiles into a module and I change one of the procedures or add a new procedure I will probably be required to test every procedure because the source changed. How do you handle this? Can you get by with testing only the changed/added code?

Because of this testing requirement I lean toward making each procedure it's own module.

Hmm. For example, lets say I have a module full of date routines, and I come across a need for a new function, say to find out what date is the first Monday of the month. I update (in a test library) /COPY book to have the new procedure interface, and I update the module code, and recreate the service program.

In most cases, I then create a small test harness program that shows how an example call would look and work, which I then actually call to try out the new function. This also comes in handy when I forget how to code up the function call for another program at later time. It also lets me know if my interface is clumsy to use, in which case, I might change it a bit at this point.

Then I use some judgement. If I haven't disturbed any of the other functions, I probably won't go to much trouble to do a lot of testing. If I'm feeling paranoid, I run my other test harnesses to make sure everything still works.

Once I'm happy with the new code, I arrange to get it into production.

Since I am grouping like functions, I do tend to automatically limit the number of functions per procedure. I would perhaps be a bit concerned to see hundreds or thousands of procedures in one module. I like to keep it in the tens of procedures or less. One procedure per module seems a bit extreme in that you may need a large number of source members on even a moderate size project.

As they say in the Perl World: TIMTOWTDI (There is more than one way to do it).

Regards,
Rich

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.