The world has become accustomed to having things instantly – instantly notified of the latest news events, groceries and household products delivered instantly, instant access to banking statements, and the list goes on. This instant culture is most definitely reflected in today’s software development organizations as many are implementing the practice of Agile in support of DevOps to deliver products to market faster and gain that competitive advantage. At the heart of DevOps is the development pipeline built upon the automated and Continuous Integration of software changes and Continuous Deployment (CI/CD) of new product builds. However, it’s important to recognize that it takes more than just automation to achieve this. It requires a cultural changes as well as investment in high quality tools for development and test of complex applications to deliver products faster with quality.
For z/OS applications, IBM provides the testing tools IBM Z Unit, IBM Z Virtual Test Platform, and the recently announced support for the open source Galasa integration framework through the IBM Distribution for Galasa. Refer to Suman Gopinath’s blog,
Testing hybrid Z applications with VTP 2.0, for an overview of these products and how they can help organizations to automate and shift left testing to deliver products faster with quality.
In this blog, we’ll dive more into the details and share an example to help understand how the IBM Z Virtual Test Platform and Galasa can be used to test the GENAPP application both before and after code deployment. GENAPP is an insurance policy application developed in COBOL that runs in CICS and uses a combination of VSAM and Db2 to persist customer and insurance policy information. We encourage you to take a closer look at GENAPP, available
here for download.
In this example, imagine a new business requirement is needed for the insurance policy to identify the number of drivers in a household. This will require changes in GENAPP to store the number of drivers in the household for each policy holder. The number of drivers in the household will be used to calculate the insurance policy premium.
Before starting development in GENAPP, a first step is to understand where changes to the code should be made. Consider using a tool like Wazi Analyze which can help to simplify the understanding of applications like GENAPP and make changes easier. Once the developer is familiar with where the changes should be made, they can implement them in the development environment.
After the code changes are complete, the next steps will be to build and test the changes made to the business logic in GENAPP before promoting the changes to the Db2 database and CICS region. This allows the developers to test the changes early in the development cycle without the need for Db2 and an active CICS environment. While the ZUnit feature can be used to unit test the changes made to the program, IBM Z Virtual Test platform (IBM ZVTP) allows the developer to verify the impact of these changes in the context of the transactions.
For GENAPP, Z Virtual Test Platform (VTP) test cases were recently created so it’s perfect to support the testing for the insurance policy code changes. The test case details the programs that have been captured and the recording dataset.
The figure below shows the results of the ZVTP test executed against the developer’s personal load libraries. The test case results show that IBM ZVTP detected a mismatch in LGICDB01 for the SQL Select statement when the customer information is queried, as expected. It is also important to note that there are no mismatches detected for the other programs – LGTESTC1 and LGICUS01 that are executed in this transaction. This test case result proves that the code changes did not have any unintended changes to the application flow.
Since the test case results proved that there weren’t any unintended changes introduced into the application execution flow, the ZVTP test case recording can be updated with the current execution. This is done by using the BZUNEXT feature of ZVTP.
At this point, the code changes have been validated with the ZVTP pre-deployment tests, the code change is ready for delivery, and the updated ZVTP tests can be added to the repository. Now it’s time to perform the changes to the CICS and Db2 environments to support the new code changes and run the post-deployment tests using Galasa.
Galasa is a powerful integration test framework that can execute tests across both IBM Z and cloud native platforms, enabling continuous integration across an entire hybrid application landscape. But since we have already executed a set of tests against the module we have changed, what else is there to test?
Like the set of concentric circles rippling from a stone thrown into a pond, even the smallest code update can cause ripples of change throughout an enterprise application. A minor change to a commarea within a CICS application can impact other legacy SOA interfaces or derived APIs being used by other applications, not just on z/OS, but on distributed, on-prem or public cloud platforms as well. Sometimes these implications will be understood as part of the project planning but may not be understood by the developer making the change; therefore, impacting the quality of the application. In the GenApp example the core of the application is CICS, which in turn is hosting a 3270 interface as well as web services and RESTful APIs each driving the same logic just updated. Each of those interfaces in turn might be consumed by other applications which also need to be tested.
For this change there will also be a set of configuration changes that will need to be updated. Perhaps new DB2Entry resources will need to be generated and deployed. Such changes are vital to the application working in production but cannot be tested by ZVTP.
It’s likely a set of tests already exists that exercises all of the interfaces and configuration changes that might have been regressed, however for applications on IBM Z these are likely to be manually-run tests. These tests are often the final gatekeeper of quality for the application and are trusted, however execution of the test is obviously slow as the tester configures the set of environments and prepares the software tools that they are going to use.
But this delay does not always fit with the accustomed expectation of instant results that was discussed at the start. This process takes time and effort but is necessary. The obvious question is “why not automate those tests?” The answer is that automating such tests is not as simple a proposition like executing a unit test. As stubs and mocks are replaced with the real services they represent, many of the services might need to be integrated together and/or shared with other tests.
In this example the objective was to add the number of drivers in a household to their insurance policy. The internal changes to allow this new field to be persisted to the database have been made. Now a regression test is required to test all of the existing interfaces to our core application, from 3270 fields to JSON APIs. Depending on the project roadmap, not all of these interfaces will have been updated at the same time with our change so we need to ensure that at the very least we can tolerate an interface not updating the new field. The existing test might contain the following code:
terminal.positionCursorToFieldContaining("Policy Number").tab().type(policyId);terminal.positionCursorToFieldContaining("Cust Number").tab().type(customerId); terminal.positionCursorToFieldContaining(“Bedrooms”).tab().type(bedroomsStr);terminal.positionCursorToFieldContaining(“House Value”).tab().type(houseValStr);terminal.positionCursorToFieldContaining(“Property Type”).tab().type(propType);terminal.positionCursorToFieldContaining(“House Name”).tab().type(houseName);terminal.positionCursorToFieldContaining(“House Number”).tab().type(houseNumber); terminal.positionCursorToFieldContaining("Postcode”).tab().type(postcode);terminal.positionCursorToFieldContaining("Select Option").tab().type("2").enter().wfk();AssertThat(terminal.retrieveScreen()).contains("New Motor Policy Inserted");Which allows for interacting with the 3270 SSP2 transaction to create a new home policy. Not only should this test code still work to prove the absence of regressions but should also now be amended to also test the insertion of the new field.
3270 is a very basic example but the Galasa framework would allow for testing any of the interfaces that the Genapp application contained within the same test class as the 3270 interactions. For example, combine creation of a new house policy using 3270 with the new field with a test obtaining it by calling a JSON API to retrieve the policy details; comprehensively testing all aspects of the application.
IBM ZVTP provides these capabilities to allow a tester to extend their agile vision across all stages of testing, from pre-deployment through to post deployment testing, regardless of the platform, or test technologies used, giving total flexibility and freedom of choice.
Written by Nathan Cassata and Will Yates.