How Polverini Enables End-to-End Testing on IBM i
August 5, 2024 Alex Woodie
Testing is one of the most time-consuming and least glamorous parts of software development. But doing it well is important, as the July 19 CrowdStrike outage so potently reminded us. When it comes to ensuring that IBM i programs are thoroughly tested, a relatively new end-to-end testing solution from Polverini & Partners can potentially take some of the drudgery and error out of the process.
Polverini & Partners recently announced ReplicTest, a new product aimed at automating all aspects of the software testing process on IBM i, including unit testing, acceptance testing, regressing testing, security testing, integration testing, and stress testing. The software works with all types of applications on IBM i, including 5250 interactive, batch, Web apps, and APIs.
In a nutshell, the software works as many other testing products do: by recording an interaction with the software to be tested, and then replaying that interaction via scripts. If the result of the script replay deviates from the norm, then ReplicTest flags the test as a failure.
But there’s a lot more to ReplicTest, and that’s what makes this product a potentially unique one in the IBM i market, according to Pascal Polverini, the founder and chief technology officer of the Italy-based software house.
For instance, ReplicTest handles much of the prep-work that goes into testing, such as copying and initializing files to be used during the test. When a user is ready to conduct any type of test, it’s just a matter of issuing the “run test” command (assuming the scripts have already been created), Polverini says.
“If I have to test some program, surely my programs are using some files. My program A will call program B that will call program C that will use other files,” Polverini tells IT Jungle. “If I want to test this, I would first have to, one, isolate all the tables, the files I’m going to use; second, copy them before I do my steps, copy them after, and then I replay my test.
“I have to re-initialize all of those tables, do the same sequence, and compare the original of each table between before and after. This is too much!” he continues. “This is discouraging. This is why no one is talking about test, because this is a pain.”
Another feature that sets ReplicTest apart is integration with Code Coverage, the IBM tool that gives Rational Developer for IBM i (RDi) users insight into how much of a particular program was tested and which parts were not touched by the test at all. While IBM developed Code Coverage with the idea of analyzing the results in RDi, Polverini rewrote the API interpreter to allow it to work with other IDEs, such as VSCode.
“Code Coverage will tell you within this program, this line has been executed and this one not. What you really want is to do is test different variations of different tests to navigate everywhere in your code, in your program, and I can give you a metric because I’ve got now the Code Coverage integrated automatically,” Polverini says. “I can tell you ‘We have 10 percent covered of program A, 80 percent of program B and 90 percent of program B.’ And with this, you will sleep better, because you have a number and not just perception.”
ReplicTest can also intelligently break apart massive test datasets to help organizations more effectively devise tests that thoroughly check more of their programs. This shrinks the data requirements of the tests as well as the time spent to run them, thereby allowing customers to run each individual test more often, Polverini says.
“It’s very rare that an IBM i shop has a subset of data made on purpose only for testing. What you do is you copy the data from production,” he says. “But if you do that, you may have a huge file with billions of records. Then your test scenario will navigate and do different things. You can have 1,000 test scenarios, and each test scenario will not choose the 1 billion records from your file. Maybe it will only 300 records or 200, a subset.”
“We developed a module to interpret which record is effectively used by your test case for reads, writes, updates, and deletes. And technically, this was a challenge because you’ve got triggers for everything, except the reads, but we found a way to understand what’s going on. Therefore, we can form a test case, extrapolate only the record that will be used, and create a subset that the replay will use from that point on for any new test.”
Load testing is important for companies exposed to the Web that could have anywhere from 100 to 10,000 users hitting their applications and their database at any given time. Devising stress tests is difficult, however, because as soon as a database record is opened for an update, that record is locked. Polverini got around that challenge by implementing variables that enable parallel operation of the script.
“Everything for us is a script. We control the script,” he says. “And we can enable you to say, ‘This number, I want this to become a variable.’ You can do this many, many times within the same script. And because everything can be coded with CL command, you can code a script with CL command. You choose your name of the variable and the value, and you can code the script, one time, 1,000 times with different values.”
Testing Web applications is notoriously difficult, as they often contain multiple jobs and threads, asynchronous connections, and RESTful APIs, “and it can end up being who knows what job under your HTTP server,” Polverini says.
“What we have done is we’ve enabled the tool . . . to encapsulate multiple threads and multiple jobs,” he continues. “I can follow any job following the user, like ‘Please encapsulate every job under Alex’ or ‘Follow and encapsulate any job with domain myserver’ or a combination of both of them.”
Polverini set out to develop the IBM i community’s most thorough end-to-end testing tool, and he just may have succeeded. By chipping away at technical hurdles to testing, automating multiple testing steps, and plugging it all into a DevOps pipeline, Polverini just may have achieved his goal of transforming software testing from a liability into an asset.
“We all know testing is important, of course. A programmer spends on average one-third of his time on testing,” Polverini said. “If you can free this time because you have a complete suite of tools to do that, everyone sleeps better, which is always good. Everything will be more solid, and you will have more time for projects, because they spend less time testing.”
Polverini & Partners rolled out ReplicTest in 2023, and the product is already being used by IBM i shops. The company expects to release version 2 next month. For more information on ReplicTest, see www.polverinipartners.com.