Code review checklist for AS/400 application

10 pts.
AS/400 applications
Hi, As part of Unit Testing process documentation, I need to prepare 'Code review checklist' for AS/400 application. Request the members to please share the same.

Answer Wiki

Thanks. We'll let you know when a new response is added.

Generally a Code Review is not include in the Unit Test Process.

The Unit Test is done by the QA staff or the end users.

A code review is the IT Developement staff looking at the actual source code.

Discuss This Question: 1  Reply

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • TomLiotta
    Unit Testing is often not done by QA and is generally impossible for end users. A Unit Test tests a "unit" in isolation. It most often is created by the developer and commonly performed by the developer, usually because of the difficulty in getting it done by anyone else. I usually first code a CL wrapper that passes in a set of known values and compares actual results to expected results. The "unit" being tested might be a procedure or a *PGM, but it will not be integrated with other elements. It will succeed or fail as a 'Unit'.   As the 'unit' is iteratively developed, the wrapper might also be developed more. Ideally, a database of test values and expected results allows the wrapper to repeat tests automatically and to test new combinations of inputs.   Unit Testing should be done all through the development of the component (the 'unit'). Depending on development methodology, the site standards and other considerations, code review probably shouldn't be done until after the developer is satisfied with the Unit Test. The code is then assumed by the developer to be ready for review. Any test wrapper can also be promoted for QA's use.   The code review should then be reviewing code that "works". The review may find numerous issues with quality or standards or simply unexpected circumstances. Because the Unit Test already exists, fixes may be tested as soon as they're made, and a subsequent review can conceivably be made later the same day, or at least it can be made soon enough that reviewers are still freshly familiar with the code.   A code review should review code that is candidate for promotion. There is less need to review code that is known will be massively modified.   As for what a code review should physically consist of, I suggest starting with two Google searches, first for [ code review ] and second for [ code review checklist ].   What works for me is unlikely to work well for you. The types of code and their purposes are likely to be very different. For example, the last major code unit I created was an interface-matching replacement for IBM's Qp0lProcessSubtree()--Process a Path Name API. That's not the kind of code most sites see. Reviews would have different focuses.   If you read a few articles on code reviews, you can then look over some of the code-review checklists already available on the internet. It's likely that many of them won't seem to apply to you, but you can cut & paste parts together to custom build one that seems to work in your environment.   When you create a first example, you might paste it back here to see if anyone can add bits that weren't obvious before. But it will be bits added to something that you think fits. It won't be something that works in some other shop.   Tom
    125,585 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: