Unit Test on IBM i (aka AS/400 or AS400)

Unit testing is a ‘white box’ approach to test the correctness of an isolated unit of code, such as a procedure, function, or method. Performed by developers, it’s a continuous part of modern DevOps, aiming to catch defects early to reduce costs. It works by comparing expected output values to given inputs, making it ideal for continuous test automation in DevSecOps.

Successful test runs are stored as baselines, and subsequent tests are evaluated against them, effectively detecting regressions. Unit tests can be reused, grouped, and run after system builds, environment changes, or before QA transfers. Early development unit tests can also “smoke test” an application to catch basic errors before more sophisticated testing.

Used continuously in a CI/CD cycle, unit testing pinpoints precisely in which lines of code the defect lies. Bugs are fixed before they ever leave the hands of the developer!

Creating unit tests as you develop code actually improves the code design and makes the code easier to understand by development teams in the future. As well as being more reliable, unit tested code is simpler, more modular, and hence more reusable. This reduces technical debt and lowers development costs in the long term.

Unit testing is ideal for modern languages with small, clearly defined units, but what about RPG and COBOL on IBM i? Modern IBM i applications with ILE architecture separate business rules, data persistence, and user interface into distinct modules, making unit test automation easy.

Legacy IBM i applications, often monolithic and decades old, still benefit significantly from unit testing. Including monolithic code in your unit testing strategy requires some refactoring. Unit testing provides a safety net as you modularize legacy code, ensuring previous deployments still work with new functionality by generating and re-running tests over backend applications.