Showcase Article - Setting up a Test Environment

Building a proper test environment can be time consuming. The time is well spent though. Aside from the obvious benefit of being able to test your program, you will get a clear picture of the data and the relationships between files when you create your test data.

Imagine that you have a program that uses three files:

1. a customer file (CUS)

2. an invoice file that has all invoices for a customer (INV)

3. a payment file that has all payments for an invoice (PMT)

Suppose you want to test the way the program handles the application of a credit memo to a partially paid invoice. Applying the credit memo will add a record to the payment file and change some fields in the invoice file. The customer file is not changed. Further, each file is read using a logical file.

Figure 1 shows the steps to follow to set up a test environment. This may look like a lot of work. The time spent setting up the test data will pay big dividends when you start testing. Not only will you be able to test easily and quickly, you will be able to prove to your users and quality assurance staff that your program is functioning correctly.

Create a Test Library

This is as easy as entering the command CRTLIB TEST1.

Isolate Test Data

The perfect tool for isolating test data is Query/400. Query will not only find the data easily but will also find the matching records in the associated files.

Typical of relational database environments, you cannot randomly select records from each of these files. That is, the invoice records must belong to a customer record and the payment records must belong to selected invoice records.

In this case, write a query to display invoices that are partially paid. From these, select several and write down the customer numbers.

Query/400 is an excellent tool for selecting the data. Now write a query to select the INV records for these customers and make a work file named INVTEST. Use the "Select Output Type" option, to tell Query that you want to create a database file as output. Name the output file INVTEST and store it in the test library, TEST1.

Write a similar query to select the PMT records for these customers. Name that file, PMTTEST.

Create the Test Physical File Definitions

Now, make a skeleton file definition for each of the files in your test library. There are several ways to do this. My favorite method is to use the WRKOBJ command to find the file in my production library and then to use selection 3 to copy the file to my test library.

For example, to copy the INV file definition from library DMCLIB, the command: WRKOBJ DMCLIB/INV *FILE will show the INV in list format. Then, by keying "3" next to it, you can copy the file definition to the test library, TEST1.

Repeat the process to copy the payments file. Remember that this builds a file with no records.

Create the Logical Files

Similarly, copy the logical file definitions. If the logical file is named INV01, use the command: WRKOBJ DMCLIB/INV01 *FILE to list the file and use the selection "3" to copy it to the test library TEST1.

Repeat the process for each logical file that you need.

Copy the Data to the Test Physical Files

Now copy the test data to the files.

For the invoice file:

CPYF FROMFILE(TEST1/INVTEST) TOFILE(TEST1/INV) MBROPT(*REPLACE)

For the payments file:

CPYF FROMFILE(TEST1/PMTTEST) TOFILE(TEST1/PMT) MBROPT(*REPLACE)

Write a Program to Restore the Data

After you test your program, you will want to restore the data to its original state before testing again. Write a simple CL program that consists of the two CPYF commands that you just used to copy the test data to the test files. Once you compile this program, you can call the program anytime you want reset your data.

Change library list and confirm location of objects

Change your library list so the test library, TEST1 is before your other libraries. For most environments, changing the current library to TEST1 is the way to do this. The command for that is: CHGCURLIB TEST1

Confirm that you created the files in the TEST1 library. Use WRKOBJ to find all occurrences of each file in your library list. For example: WRKOBJ INV *FILE will list all INV files in your library list. The first one in the list should be in the TEST1 library. If not, stop! The whole point of setting up this test environment is to ensure that the INV file used for testing is the test copy in TEST1.

When you run your program, the AS/400 looks through your library list for each object that it needs. If you compile your test program in TEST1, that is the one that will be called. Likewise, when the program reads or updates data in the INV or PMT file, it will use the files that it finds first. In this case, it finds the files in TEST1 and uses them.

In the case of the CUS file, the AS/400 will not find the CUS file in the TEST1 library. That works fine because the CUS file is not updated by this program.

You can now test your program without harming any production data. You can also restore your test data by calling the CL program that you just wrote.

We have followed some important principles of testing. These include:
· Have a defined test bed of data that can be restored
· Have test copies of all data that is modified
· Test the final version of the program. That is, do not construct a test that requires changing the program after testing is complete.   In other words, don't disable the UPDATE's in a program so you can test without altering data.
· Keep all test objects in an isolated area.

You now have a seven step process to follow when testing. It requires no high level language programming. You need only knowledge of a few commands and the ability to write simple queries.

Figure 1 - These are the steps to set up a test environment.
 
1) Create a test library
2) Isolate test data from each of the files that are changed
3) Create the test physical file definitions
4) Create the logical files
5) Copy data to the test physical files
6) Write a program to restore the data
7) Change library list and confirm location of objects