+

Search Tips   |   Advanced Search

(ZOS) Testing and production phases

Before explaining the test and production configurations for the product, we must understand which test phase should be done on the z/OS platform and which should be done on other platforms.

Sharing resources between a production workload and a test workload can expose the production workload to a set of error conditions to which it is not exposed if the production and test workloads run in different cells. If possible, we should run production and test workloads in separate cells on the system..

Before setting up your test and production configurations for the product, we must understand which test phases should be done on the z/OS platform and which should be done on other platforms. The following sections explain the different phases:


Unit test phase

Applications that we plan on running in a z/OS environment should be developed on a distributed operating system, such as Windows or Linux Intel, on which the product is installed. These development environments contain assembly tools for web content delivery that are not available on z/OS. The IBM tooling solution assumes that you develop enterprise beans in one of these tools and perform basic testing of the business logic in the distributed environment before moving the application to the z/OS environment.


Component test phase

Component testing involves the joining together of several enterprise beans into logical components, providing them with access to data, and testing them together. While this can be done on a z/OS platform, IBM recommends that we do this level of testing on a distributed platform. Performing this type of testing on a distributed platform enables a small team of developers to join the code pieces together and test the interactions. This type of testing focuses on the individual beans and their relationships to each other rather than z/OS platform functions and features.


Function test phase

Function testing involves joining the various components together, connecting them to test data in the target database, and validating the function that the application provides. Where this test is performed depends on the function and its data requirements. If the target deployment platform is z/OS, we might want to do this level of testing on z/OS. In this situation we should install the applications that we are testing on one or more servers that are only used for testing.

When we install the application on a test server, define where in the JNDI directory the references to the application are stored, and then configure the test clients such that they know the location of the test application. The test clients can then drive requests against the test server to perform the functional testing. Use remote debugging tools to diagnose problems we encounter along the way.


System test phase

Before you put an application into production on z/OS, we should install the application into a system test environment on z/O and simulate a real workload on that application. When setting up the system test environment, we should define an additional test server on a cell dedicated to the test system, and install the application onto that server. When installed, enterprise beans that are part of the application should be registered in a different subtree of the JNDI directory. This normally happens by default but it is good to verify that this registration occurs. The test clients must be configured to the version of the application being used tested before we run your tests.


Production phase

After we are satisfied with the functional and system testing, install the application in a cell used for production . The difference between a production cell and a test cell is whether the remote debugger is allowed to be attached. Normally, it is not acceptable for a production workload to stop because a remote debugging request is sent to the cell.


Subtopics