Written by Dan Donnelly, Software Tester
For anyone not familiar with Galasa, it’s an open-source test integration tool that allows you to create tests to run in automation on z/OS (https://galasa.dev/). It contains a set of Managers that allows your tests to easily interact with features and systems on z/OS such as, HTTP, CICS, MQ etc. I’m part of a development group working with Kubernetes on z/OS. We wanted to take advantage of Galasa to write and automate tests on z/OS, as the Galasa Managers make it much easier to write tests that interact with z/OS. Initially all our Galasa tests were running on local machines using the Galasa Eclipse plug-in. This obviously wasn’t ideal, as it required someone of have access to an individual’s machine to run the tests. This is a description of how we moved those tests from running on local workstations into automation. Our CI/CD solution is currently based around Jenkins, so below is a description of how we managed to run our Galasa tests as part of a Jenkins pipeline.
The Initial Set-up
The diagram below shows our initial test set-up, with the test code running on a local workstation, interacting, and testing features on a z/OS LPAR.
Diagram showing Eclipse with a Galasa and Maven plug-in install on a local workstation initiating tests on a z/OS LPAR
The Galasa Command Line Interface
Firstly, we needed to find a way to run the tests on a Linux server instead of a laptop, and without using the Galasa Eclipse plug-in. Galasa has implemented a Command Line Interface, which makes running tests outside of Eclipse a reasonably straightforward task. We could run our tests using a command similar to the one below:
Moving the Tests on to a Server
Once we could run the tests in the CLI, the next step was to move them onto a server before automating them. We intially looked at using a Galasa Ecosystem to do this (https://galasa.dev/docs/ecosystem), but due to local constraints, this wasn’t going to be an option for us. One of the main benefits of running in a Galasa Ecosystem is that it can manage a pool of resources shared between the tests (such as port numbers). Fortunately, none of the tests we were automating had any shared resources, so we could run the tests on a server, without a Galasa Ecosystem, using the galasactl run submit local CLI command. The diagram below shows how the test infrastructure looked once it was moved on to a Linux server:
Diagram showing test code being checked out of Github onto a Linux Server where it is compiled using Maven, before being run by the Galasa CLI. The tests then interact with a z/OS LPAR
As can be seen from the diagram, the Galasa test source was pushed from the local IDE instance into a Github repository. To run the tests, the following steps needed to be performed on the Linux server:
- Checkout the Galasa test source out of the Github repository.
- Compile the Galasa source using a Maven clean install.
- Issue a local run of the tests using the Galasa CLI
The Galasa tests could then run against the z/OS LPAR they were configured to run on in the Galasa cps.properties file.
Automating the Tests
Once the tests were on the server, we could automate them by using a Jenkins pipeline. To do this, we set up the Linux Server as a Jenkins node, and then created a Jenkinsfile to inform the pipeline what needed to happen. An example Jenkinsfile is show below:
In our case we pushed our Jenkinsfile to the same repo that contains our Galasa test code. We then created a Jenkins pipeline to automate the running of the tests.
Conclusion
At the start of this process, we had Galasa tests being manually run by individuals on local workstations, and by the end of it we had automated tests in a Jenkins pipeline that could be run by anyone with the correct access. The main benefit of this is that because the tests reside on shared infrastructure, we avoid having individual points of failure (in the form of individual laptops) to run the tests. The additional benefit was that now everyone in the team, at a glance, can see if tests are passing or failing, instead of having to rely on reports from individuals. We can now also schedule tests to run on a regular basis, which gives us a much better understanding of code and test quality.
If you want to find out more about Galasa and get involved, go to https://galasa.dev or https://www.github.com/galasa-dev, or to reach out to the team and ask how they could help you get up and running, go to the OMP Slack and search for #galasa-users to get help on your next steps to application integration testing.
