[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Application Server Integration Tests

[rachmatowicz@jboss.com]

I have had a look at the existing framework for incorporating Joram tests into the testsuite. As it is a candidate approach for the integration of generic JMS test cases into the testuite, i'd like to summarise how it works and what I feel are its advantages and disadvantages.

The framework involves defining several sets of classes. The class hierarchy looks like this:

--------------------------------------------------------------------------------------------------------------
TestCase                       
AbstractTestCase
AbstractTestCaseWithSetup    TestSetup
* ----------------------->   AbstractTestSetup  
                              *  -------------->  AbstractTestDelegate  
                                                  JoramTestDelegate                  Admin  
                                                                           GenericAdmin   AbstractAdmin
JoramTestCase                                                                             JBossASJMSAdmin
JBossMQJoramUnitTestCase                                                                  JBossMQAdmin
----------------------------------------------------------------------------------------------------------------

Each column represents an inheritance hierarchy. The classes to the right based on Admin are a separate hierarchy. An asterisk and dotted arrow is intended to represent a member object, pointing to its type in the hierarchy (i.e. AbstractTestSetup holds an instance of JoramTestDelegate)

How is it used? (llosely speaking)
1. You implement a subclass of JoramTestCase (e.g. JBossMQJoramUnitTestCase) which implements the method getDelegate(). 
This method specifies the name of the Admin implementation you want to use .
2. You implement a JMS provider-specific class implemnting the Admin interface as a subclass of JBossASJMSAdmin (e.g. JBossMQAdmin)
3. You write your generic JMS tests using JBossMQJoramUnitTestCase as your baseclass, and include code snippet similar to

  Admin admin = AdminFactory.getAdmin() ;
  admin.createQueueConnection(TEST_QUEUE) ;

to create JMS destinations and connections.

How does it work?
1. The Joram test cases are hardwired to use an AdminFactory to load the class GenericAdmin as the Admin implementation.
This class holds a member object which is initialised at run time and to which all JMS admin functions are delegated.
2. Whether the JMS tests to be executed are individual tests or a test suite, the AbstractTestSetup class gets called
and is reponsible for ensuring that the correct implementation of JBossASAdmin gets initialised in GenericAdmin.
3. The JMS test cases don't need to do anything special other than use the code snippet above.

This approach is used and works well for incorporating the Joram tests into the testsuite. 

Problems with this approach:
1. JoramTestCase does not subclass from JBossTestCase, and so all calls to methods defined in JBossTestCase already present in
the existing test cases will have to be recoded. JBossASJMSAdmin does incorporate an instance of JBossTestServices within
it, but it does not provide an interface to all of the functions available in JBossTestCase. 

2. In order for AbstractTestSetup to be called when executing a test suite, the test suite needs to be wrapped in an 
instance of AbstractTestCase. Forgetting to do this will result in the Admin class not being correctly initialised. 

3. It takes time to find out how the class hierarchy works (for example, processing of test cases follows a different
procesing path than for test suites), and this makes debugging and maintaining more complex.

All in all, I am in favour of using a simpler approach, based on the simplified scheme described above, where test cases
continue to sublass from JBossTestCase, and the only changes to test cases required are (i) the loading of the Admin class
based on AdminFactory and specifying the Admin implementation via the property jms.provider.admin.class, (ii) replacing
JMS specific calls to create destinations with calls to Admin (iii) making all desintaion names JMS provider neutral.

This seems to me to be a faster approach and one which will work. If I have missed some obvious advantage of the more 
complex scheme, or am misrepresenting it, please point it out. I plan to begin converting one or two JBossMQ tests to the generic form based on
the simple scheme over the next few days to see that everything works in practice.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975040#3975040

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975040