Modern Testing Strategies for IBM i Application Development - Laying the Foundation for Quality in RPG and CL Environments 

For decades, IBM i has earned its reputation as a rock-solid platform. Yet in today’s fast-moving, customer-driven development landscape, stability is no longer enough. Applications must also be rapidly adaptable, secure, and resilient — without compromising on quality. This expectation introduces new pressures for development teams, particularly those still relying on legacy practices.

One area where this tension is felt most acutely is in testing. For as long as I can remember, I’ve observed many customers undervalue or relegate serious testing to the final stages of delivery. However, the times are changing and testing is beginning to take center stage in many of our customers. As IBM i teams modernize, testing is no longer a nice-to-have — it’s a critical component of software health and delivery speed.

DevOps, Agile, and the Push for Quality

The growing—though slower than many expected—adoption of Agile, DevOps, and CI/CD practices, even within traditional IBM i environments, is gradually raising the profile of testing. These modern methodologies aim to accelerate delivery, but they also require greater consistency and higher standards for code quality.

Unfortunately, many IBM i shops continue to rely on manual testing, anecdotal QA processes, or even end-user verification. These approaches are slow, error-prone, and incapable of supporting continuous change. The result? Bug-prone releases, unexpected regressions, and delayed value delivery.

In modern software development, unit testing is a baseline expectation. But on IBM i — particularly in RPG and CL environments — unit testing is still an emerging practice. The reasons are understandable: historically, the platform lacked testing frameworks, and many RPG programs are tightly coupled and difficult to isolate for testing.

But that’s changing. Lightweight testing tools for RPG now exist. More importantly, a shift in mindset is taking place: IBM i developers are beginning to embrace the idea that testable code is better code — easier to maintain, easier to refactor, and safer to deploy.

If it’s hard to test, it’s probably hard to maintain.

Why Unit Testing Matters

Unit tests provide a safety net during refactoring, support regression prevention, and improve onboarding for new developers. As organizations modernize their IBM i applications, unit testing offers a practical way to incrementally improve confidence in legacy code without rewriting it entirely.

Embracing Shift Left – With Realistic Expectations

The industry-wide “shift left” movement — bringing testing (and security) earlier in the development cycle — is widely seen as a best practice. But it’s not without cost. I’ve noticed, almost without exception, that the burden of quality assurance increasingly falls on developers, who are now expected to write, run, and maintain tests in addition to delivering new features.

Management often overlooks this reality. Without investment in automation, this shift simply increases developer workload and introduces bottlenecks. Automated testing tools, test harnesses, and pipelines are essential to scale quality efforts without slowing down delivery.

The message is clear: if you're shifting left, you must automate.

Where Automation Delivers the Greatest Impact

Test automation doesn’t mean attempting to automate every possible test. Instead, it means automating consistently where value is highest:

• Unit Tests: Run automatically as part of a build or CI process{color} 
  * Smoke Tests: Run after deployment to verify basic functionality
• Regression Tests: Catch issues introduced by code changes

Modern DevOps platforms and scripting tools (such as Jenkins, GitHub Actions, or dedicated IBM i DevOps solutions such as Rocket DevOps) can trigger these tests as part of your delivery pipeline. When combined with version control and build automation, test automation forms the backbone of a resilient delivery process.

Culture Matters: Encouraging Developer-Led Quality

Adopting testing on IBM i isn’t just a technical challenge; it’s often a cultural one. Many teams are still operating in siloed roles where QA is separated from development, and testing is reactive rather than proactive.

To overcome this:

• Encourage developers to own quality — not just code
• Include testing goals in sprint planning and performance reviews    
• Provide training and time to adopt new testing practices
• Align testing metrics (e.g., code coverage, test pass rate) with business KPIs

A Realistic Path to Test Adoption on IBM i

For IBM i teams just starting out, testing transformation can feel daunting. But it doesn’t have to be all or nothing. Here’s a realistic path forward:

1. Start with new code: Introduce unit tests for any new RPG programs or service programs.
2. Target high-risk areas: Identify legacy code that frequently changes or causes issues and build basic test coverage there.
3. Automate the easy wins: Smoke tests and syntax validation can often be automated with minimal effort.
4. Invest in tooling: Whether open-source or commercial, tools that support RPG unit testing, code analysis, and automation are available — and worth the investment.

Final Thoughts: Confidence Through Testing

Modern testing is not about perfection — it’s about creating feedback loops that help teams catch issues early, reduce manual labor, and deploy with confidence. For IBM i teams modernizing their development practices, robust testing is the first step toward resilience and agility.