geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anders Hessellund Jensen <...@trifork.com>
Subject Re: Geronimo ORB progress
Date Wed, 16 Nov 2005 14:15:12 GMT
David Blevins wrote:
> So what kind of testing framework is this? Is it junit-based?

Yes, it is junit-based. Essentially, we have created a test superclass, 
which inherits from junit.framework.Test.

So, assume we would like a Multi-JVM test with a single test case named 
"Simple". We have two JVM's, a client and a server. The client and 
server each needs to do some initialization, then the client initiates a 
test, and finally the server needs to do some checks after the test.

A multi-JVM junit test would look something like this:

class MultiJvmTest extends RemoteTest {
   public void setUp() {
     // Starts a JVM named "server"
     startTestAgent("server");
     // Starts a JVM named "client"
     startTestAgent("client");
   }

   public void serverBeforeSimple() {
     // Setup the server for test case "Simple"
     // This method will be invoked in the "server" JVM.
   }
   public void clientBeforeSimple() {
     // Setup the client for test case "Simple".
     // This method will be invoked in the "client" JVM.
   }

   public void clientTestSimple() {
     // Run the test
   }

   public void serverAfterSimple() {
     // Check server state after test.
   }
}

When running this test, the framework would do the following:

- run setUp(). This starts the two JVM's identified by the strings 
"server" and "client". Thus, there is three JVM's running in total, a 
master JVM, and two slave JVMs.
- invoke the serverBeforeSimple() in the "server" JVM.
- invoke the clientBeforeSimple() in the "client" JVM.
- invoke the clientTestSimple() in the "client" JVM.
- invoke the serverAfterSimple() in the "server" JVM.

The whole thing integrates pretty well with junit. If an exception is 
thrown in a slave JVM, it will be rethrown in the master JVM, resulting 
in a correct stack trace identifying where the test failed. Furthermore, 
it is possible to start an agent within the master JVM, so single-step 
debugging is possible as well.

Communication between the JVM's takes place using plain RMI.

An agent can be given a Properties as argument. There is also a global 
set of properties shared by all JVMs.

The framework uses reflection to collect the methods that is called when 
the test is run. The methods must be named:

<agentName>Before<testName>
<agentName>Test<testName>
<agentName>After<testName>

> How does it related to our existing itests?  Those are server (and  
> database) agnostic and can be ran across several vms and orbs.  Don't  
> know if there is any overlap.

I don't know how the existing itests work. There may be some overlap.

> Would these test be run as part of a normal build or would we set  them 
> up to run periodically in continuum or something?

These tests are intended to be run as "normal" junit tests. Thus they 
should be part of the normal build.

> Are the tests focused on verifying corba compliance or is this  somehow 
> more generic and applicable to testing in general?

The framework is quite general, but of course tailored with the features 
we needed. There is nothing CORBA-specific in it.

I would be happy to know if there is code out there that does something 
similar to this framework. We have looked around, but haven't really 
found anything that seemed quite right to our purpose.

Anders

Mime
View raw message