A Testing Tip
June 17, 2009 Ted Holt
|
One of the annoyances of maintenance programming is that testing a program change often takes longer–even several times longer–than the process of making the change. One impediment to testing is the inordinate amount of time required to load a test database with the data appropriate for a good test. In the following paragraphs, I share a simple tip that in some situations reduces the effort to establish a good test environment. Many shops maintain a separate system (either another computer or a logical partition of the machine that houses their production system) for program testing. This testing system may contain old production data, although for security reasons, it is better that the testing system not contain old production data. The test data, whatever its source, is often inadequate for robust testing, for at least two reasons. First, the data in the test database may not contain enough variety or enough invalid data to properly exercise all parts of a program. For example, suppose a program reads an invoice, then must randomly read (i.e., RPG chain) the customer to whom the invoice was sent. In a clean production database, the random read never fails. If the test data is an old copy of a production database, the case of a failed random read may not get tested. Second, test database files are often too large to manage. A programmer does not need to sift through a 200-page report to verify that a program works correctly, and shorter run times make quick work. For reasons like these, I prefer to test with small database files in a scratch library of my own, then run a final test against the official test database. But building such a database contributes to the long testing time about which I complained in the first paragraph, especially when a program uses more than a few files. If a program uses logical files, you must first copy the physical files, then recreate the logical files, and this is a process that gets messy quickly. Here is a timesaver that has come in handy for me on many occasions. When you copy a logical file and specify CRTFILE(*YES), the created file will be a physical file that looks like the logical file. Obviously this only works for single-format logical files. In the following example, logical file MROITEM serves as a pattern for physical file QTEMP/MROITEM.
CPYF FROMFILE(MROITEM) TOFILE(QTEMP/MROITEM) +
CRTFILE(*YES) NBRRCDS(5)
The new physical file contains five records. Use your favorite database utility to edit the new physical file as often as necessary, keying the values you need to get a good test. You don’t have to worry that a logical file points to a wrong file or file member. You won’t worry about select/omit criteria that might keep your test data from being selected. In the case of a join logical file, you won’t have to determine which of the various underlying physical files a field comes from in order to key in the desired data values. Once you’ve tested satisfactorily with the dummy physical files, by all means run a test against the regular test database. Hopefully, there will be no surprises and your program changes will be ready for production.
|
