Close menu
Open menu

Testing across environments

Ideally, you want to avoid hard coding within your test. If you hard code target hostnames, port numbers and so on, you can't run the same test against different environments without changing the test code.

In Galasa, when an annotation refers to a resource, for example a z/OS image, you can use the imageTag attribute to avoid hard coding the endpoint of that z/OS image in your test code. The properties that are associated with the attribute are stored in the CPS file.

Galasa Managers use attributes and their associated properties to bind a test to an environment at runtime. Using attributes to enable late binding of the test material to the system under test allows the same test to run against multiple environments without changing the test itself.

An example using SimBank

Let’s look at an example in the SimBank test code where the imageTag attribute is used to avoid hard coding an endpoint for a z/OS image.

The test declares that a z/OS image is required for the test to run and that this image is called SIMBANK by using the following test code:

    public IZosImage image;

When the z/OS Manager reads the code, it creates a z/OS image by using the imageTag attribute to ascertain which set of properties from the CPS it needs to load to create that image.

In this example, the following properties are associated with the SIMBANK z/OS image in the CPS file:


Building on the SimBank example

When you create your own test that runs against a z/OS image, you probably want to call that image something other than SIMBANK. For example, you might want to use an image called zosImage1.

You can do this by editing the CPS file to contain the properties that you want zosImage1 to have and by declaring zosImage1 in your test code, as per the following steps:

  1. Edit the CPS properties file (either locally or in your ecosystem) to define the properties of the image:
  1. In the test code, declare a z/OS image called zosImage1:
   public IZosImage image;

The z/OS Manager reads the test code and creates the image object by using the properties associated with zosImage1 in the CPS file.


What if you want to run your test against an image in a cluster? By editing the CPS properties file, you can define clusters containing images against which your test can run . Once defined, Galasa can dynamically select an image from that cluster at run time.

For example, you might want to define a cluster called CLUSTER2 which contains two z/OS images called IMAGEA and IMAGEB. You can do this by udpating the CPS file to define CLUSTER2 and the images that you want it to contain, along with the properties of those images, as per the following example:


The images are linked back to the CLUSTER2 cluster by using the following code:


In the test code, set the imageTag to CLUSTER2, as per the following example:

   public IZosImage image;

When the test runs, Galasa dynamically selects either IMAGEA or IMAGEB from CLUSTER2 at run time.

For example, in the CPS file IMAGEA has a maximum number of slots set to 1. If that slot is in use, Galasa binds the test to IMAGEB at run time, if IMAGEB is available. Images can be added to CLUSTER2 by updating the CPS file, without the need to recompile the test.

In this way, Galasa manages the inbound workload of tests and splits them across LPARS. Only when a test is told where it can run is it bound to that environment.


If you see an error message in the run log indicating that a property is not found, check that the property is spelled correctly in your test and if so, check that the property is defined in the CPS properties file.