AS/400 unit testing documentation

45 pts.
CL Commands
RPG Code
Hi, I'm doing one application with coding of RPG and CL. I'm new in this tech. I want to clarify one thing. Please can anybody tell me? When can I start unit testing and when can I end the unit testing? Please give me an example? What is meant by documentation? How can I write the documentation?

Software/Hardware used:

Answer Wiki


Yor are in the wrong field of work

Discuss This Question: 1  Reply

Send me notifications when members answer or reply to this question.
  • TomLiotta
    Unit testing can begin as soon as you have anything that successfully compiles. The system will find a lot of possible problems much faster than you will. You don't need the "unit" to do everything on your first tests. If you have input or output parameters, all you need is enough code to define the parameters and run. It doesn't need to do anything but receive some input parameters and put some values in any output parameters. On the next test, have some new code that does the basic processing of values in the parameters. If you write a RPG program that accepts a date as a parameter and prints a report of records from a file for that date, then have your first test do nothing but accept the date and then stop. On your next test, include the database file and read records that match the date. On your third test, have your printer file defined and print just the basic detail lines. Each time you run a new unit test, verify that it does the new parts correctly. Then add the next functions and run a new unit test. Build the complete function in layers. Start with the general structure. Test only that the structure works. Add detail to fill in the structure; then test again. Each time, it's a new layer of complexity. Documentation... it has to start with the standards that are in place. I'm not sure anyone can tell you what your documentation should be unless they know a lot more about your environment. Certainly the purpose of the function and the interfaces to the function should be clearly described. How those descriptions should be created can be very different for different sites. Ideally, the programming should be "self-documenting". Procedure names should say what the procedure does -- e.g., CalculateSalesTax. Variables should be named according to what the value represents -- e.g., InvoiceTotal rather than Amount or just Total. Procedures should act on variables according to what their names imply -- e.g., a CalculateTax procedure shouldn't also add the tax to the total. If code makes sense when you look at it, the need for additional documentation is reduced. Why write a lengthy description of what a procedure does if it's obvious from the code itself? If names are accurate, the need for documentation is reduced. How much can you say about a procedure named CalculateSalesTax? Best advice is to look at examples from your site and also to look at any standards for your site. There may be a Standard Procedures manual (or a Standards Wiki or almost anything). In my current position, we have defined procedures and document standards for essentially every action -- we're an ISO-9001 site. We document everything, so I'm not the best source for you. I hope That was enough to get you going in a direction. I'm sure others can add a lot of detail and provide a number of variations. Tom
    125,585 pointsBadges:

Forgot Password


Your password has been sent to:

To follow this tag...




Share this item with your network: