Java Tip 73: Test your Java/CORBA server from the inside

Learn how to test your server classes from within the running server by dynamically loading and executing test classes inside the server's virtual machine

By Charles Lerose, JavaWorld.com, 05/01/99

When we write our server code in Java, we have easy access to dynamic loading on a very granular scale. This dynamic loading is the key to a solution for our testing challenge. A few lines of extra code in the server enables thorough testing of the server while the server is running. A test sequence we wish to perform can be placed in a test class which the server can be directed to dynamically load and execute by name.

Figure 1 shows a set of objects within a CORBA server. The lollipop or jack is a simple way to denote an interface -- a set of related operations. The arrow flowing into the jack shows usage of that interface. Imagine an object on the server side that is not directly exposed to the ORB. In this figure, you'll find just such an object, an object of the CustomerStorage class. Thorough testing of the CustomerStorage class from the client side may be difficult or impossible. But to instantiate objects of the CustomerStorage class from a freestanding test program also may be undesirable due to its dependency on the Customer class.

We don't have to live with the limits of either approach. We can test our server code in place, while the server is running! Again, the key is Java's ability to dynamically load a class and to instantiate new objects of that class. In effect, we will inject our test code into the server. The first step is to define a Java interface that our test classes will implement. Our CORBA server will know nothing of the test classes, but it will know of this new interface. We define this interface to eliminate static dependency of the server to specific tests. We can write as many test classes as we like, without ever having to recompile the server.

To keep things simple, we define a test interface called InjectableProgram, with a single operation called start:

      interface InjectableProgram {
            void start();
      }

Each test class must implement this interface. Believe it or not, half our work is done. A test class named CustomerStorageTest that implements InjectableCode, can be loaded and executed with the following code fragment. We will use a more flexible variation if this fragment is in our server.

      Class c = Class.forName("CustomerStorageTest");
      InjectableProgram program = (InjectableProgram) c.newInstance();
      program.start();

It's almost that simple!

The package java.lang contains a class named Class that looks a bit like this:

      package java.lang; ... public class Class { public static native 
      Class forName(String className); public native Object 
      newInstance(); ... }

Class contains a static method, forName, that will dynamically load a Java class and return an instance of the type Class that represents that loaded class. The forName method expects as a parameter a fully qualified class name, and the named class must reside in the classpath of the virtual machine in which forName is called. Bear in mind that only the first occurrence in the classpath of a class with that name will be found by forName.

We can call newInstance on the Class object returned by Class.forName() to create new objects of that named class. newInstance will only succeed if the class in question has a no-arg constructor and has the appropriate visibility to the caller. For example, if the class has only package visibility and resides in a different package than the caller, newInstance will fail.

If that loaded class implements InjectableCode, then we can successfully cast the returned instance to an InjectableCode, and invoke methods on it. This example invokes the start method. The start method could perform tests of other classes within the server. Of course, the loaded class is subject to the normal visibility restrictions of all classes in the system. For example, it cannot access methods with package visibility on classes outside its own package.

Notice that earlier I said "almost that simple." In the example above, the class name CustomerStorageTest was hard-coded. What we really want is to select the test class at runtime. Since this is a CORBA server, why not define a new CORBA interface for injecting an arbitrary test program into the system? Let's revisit our earlier diagram but with a few new features.

Here we have exposed a new interface, called Injector, to the ORB. This gives us a way to tell the running server which test to run, or to inject into itself. Here's the definition of that interface in CORBA IDL.

       module Injection {
            interface Injector {                     void inject(in string className);
            };
      };

This interface provides just one operation named inject, which takes one parameter: the string name of the class to inject into the server. The implementation of inject must load the specified class, create a new object of that type, and then call the start method on the new object.

    public void inject(String className) {
        try {
            Class c = Class.forName(className);
            InjectableProgram program = (InjectableProgram) c.newInstance();
            program.start();
        } 
        catch(Exception ex) {
            ex.printStackTrace();
        }
    } 

Now it really is that simple!

Note that the methods of Class may throw exceptions that we must catch. Here's a client code snippet to request the test.

 Injector server = InjectorHelper.bind(...);
 server.inject("CustomerStorageTest");

A generic client program could accept a command line argument that specifies the fully qualified name of the test class to inject.

Free Download - 5 Minute Product Review. When slow equals Off: Manage the complexity of Web applications - Symphoniq

Free Download - 5 Minute Product Review. Realize the benefits of real user monitoring in less than an hour. - Symphoniq