We could move all the stuff in  MultipleCacheManagersTest.java,  AbstractCacheTest.java and  AbstractInfinispanTest.java into a Container and hide it from the user view. Using the Enrichers to inject the Cache etc..

Benefits would be:

• TestNG and JUnit support
• Abstract TestNG and JUnit integration code out of Infinispan
• Leverage Arquillian extensions like Performance Monitor
• Should be possible to test Infinispan standalone and in JBoss AS
• The user can test Infinispan in the same way/framework as other JBoss projects, familiarity
• ??
• profit!

What would be the requested features for embedded mode? Anyone can comment...

From the above links pointing to tests I can see that every test overrides a createCacheManagers() method which basically configures all the cache managers/caches. This should be somehow preserved, IMHO. Configuring all the cache managers via xml file (arquillian.xml) might be too expensive and inconvenient.

We could of course inject cache/cache manager instances directly into a testclass but they would need to be preconfigured:

1) via arquillian.xml file ?

2) via configuring cache managers in @BeforeClass method? (simulating createCacheManagers() being invoked) ?

Any comments?

I think there are two ways to go:

1) Let users inherit from MultipleCacheManagersTest.java (but rename it properly) and let them write their @Before/@BeforeMethod methods where

   they would intialize their cluster of infinispan instances. This would mean removing all the testng related stuff from all superclasses and handle this

   by reacting on arquillian event (@Before, @After, ...) internally.

   This would look e.g. like:

   @RunWith(Arquillian.class)

   class TestClass extends ClusterManager {   //ClusterManager is MultipleCacheManagersTest renamed

   @Before

   void setup() {

        CacheContainer cm1 = ...

        CacheContainer cm2 = ...

        registerCacheManager(cm1, cm2);   

   }

   @Test

   void testMethod() {

        cache(index).put(xx)

        manager(index).getStatus()

        tm(cache)...

        ...

   }

   }//TestClass

   The benefits would be (besides those mentioned by Aslak):

   * users could use the framework almost the same way (not overriding createCacheManagers but writing a @Before/@BeforeMethod method  

      initializing their cluster), there would be methods like cache(index), manager(index), tm(cache) , i.e. methods inherited from MultipleCacheManagersTest.java

   Drawbacks:

   * need to always inherit from the predefined class

2) Let users inject the MultipleCacheManagersTest.java into a test (of course, rename this class)

   and operate on caches/cache managers via this injected instance. This would look e.g. like:

   @RunWith(Arquillian.class)

   class TestClass {

   @InfinispanResource

   ClusterManager clusterManager;

   @Before

   void setup() {

        CacheContainer cm1 = ...

        CacheContainer cm2 = ...

        clusterManager.registerCacheManager(cm1, cm2);   

   }

   @Test

   void testMethod() {

        clusterManager.cache(index).put(xx)

        clusterManager.manager(index).getStatus()

        clusterManager.tm(cache)...

        ...

   }

   }//TestClass

   Benefits would be that we don't have to inherit another class.

   Drawbacks:

   * a bit longer syntax when using caches, managers, etc.

Both of these approaches would allow to point to an xml config file for infinispan and create caches based on them inside "before" methods.

Any other ideas?

Well, in order to be able to use TestNG, one has to extend an Arquillian class co the first option may not be possible:)

Sorry for jumping in on this so late.  Either approach looks good to me, however, it would also mean a lot of work to patch the existing test suite.  Can you think of an easy way around this? 

Hmm, I don't see an easy way around. This functionality could be added just for end users. We don't have to refactor infinispan test suite if there's no need to do it. Regarding which approach to follow, Pete suggested no. 2 since it's more flexible and I'm for it too.

Refactoring would be crazy to do. I think it'd be easier to build any new tests this way which at the same time gives us some time to get familiar with it and see it works for us as expected. I prefer option 2 as well.