First, you need to think like a QA person and not a developer.
A developer will try to prove that their code works.
A QA person will do everything they can to break the code.
You want to test the process from beginning to end.
Create situations that can cause errors.
Input file is blank
No member exists in the input file
Input file has corrupt data
Input file has data you have not coded for.
Input file has duplicate data
Ouptut file does not exist.
There are locks on objects.
Verify programs are passing and receiving parameters correctly.
This is a short list but should get you started in the right direction.
There is no <b>type of error</b> to check. You check for <b>any</b> error.
In order to create a module, you need to know what it must do. When you test, you check first to see if it does what it is supposed to do. Once it works, then you check to see if it does things that it’s <b>not</b> supposed to do.
Does it handle all parameter values? Check incoming parameter values that you expect to work correctly. After those work, check values that you expect not to work correctly. Make sure your module handles invalid values as well as valid ones.
Does it have side effects? Some procedures might be expected to have effects outside of the procedure. For example, you might open a file that is used elsewhere in the process. But there might be side effects that should <b>not</b> interfere elsewhere. Global variables might be improperly altered for example.
In general, does it do what it’s supposed to do, and does it <b>not</b> do what it’s not supposed to do?
I usually create a simple ILE CL procedure that calls my procedures multiple times with various parameter values. This CL can be used over and over as the module is developed. And it is immediately useful for testing the interface itself — the number and types of parameters — which is the first thing that has to be correct.
A “unit” test implies that the effects of the “unit” can stand on their own. Nothing else should create the same effects; and the unit shouldn’t cause effects that belong to other units.
But no one else knows what those effects are.
If you design a module, then you are responsible for knowing the effects. The designer knows what to test. The designer creates the specifications and the specifications are what the programmer tests against. If the specifications say that a date should be returned from the procedure, then you test to verify that the returned value is a valid date. If the procedure is supposed to update a record, then you verify that the correct record is updated correctly.
If you test that the valid ranges of parameter values work correctly and that invalid values are correctly handled, and if the there are no unintended side effects, then there’s nothing else to test.