[infinispan-dev] ISPN-ARQUILLIAN - embedded mode

[Galder Zamarreño]

On Sep 26, 2011, at 5:42 PM, Martin Gencur wrote:

> On Mon, 2011-09-26 at 15:50 +0200, Galder Zamarreño wrote:
>> On Sep 22, 2011, at 2:45 PM, Martin Gencur wrote:
>> 
>>> Hi,
>>> I'm currently implementing support for testing of embedded caches in
>>> https://github.com/mgencur/infinispan-arquillian-container project and
>>> would like to discuss future steps.
>> 
>> Are you expecting to host/maintain this separate from the Infinispan source code?
>> 
>> If not, wouldn't it make sense for it to leave within Infinispan as a separate module(s), preferably just one?
>> 
>> It'd make it easier to maintain...
>> 
> 
> I was expecting to maintain it separate from Inf. source code, but only
> a few classes which would point to functionality of
> MultipleCacheManagersTest and other test helper classes.

Ah, if it's only scaffolding and the core logic of MultipleCacheManagersTest stays in Infinispan, then I'm fine.

> 
>>> 
>>> As mentioned in http://community.jboss.org/message/551784, the tests
>>> should look like this:
>>> 
>>> @RunWith(Arquillian.class)
>>> class TestClass {
>>> 
>>>  @InfinispanResource
>>>  DatagridManager datagridManager;
>>> 
>>>  @Before
>>>  void setup() {
>>>       CacheContainer cm1 = ...
>>>       CacheContainer cm2 = ...
>>>       datagridManager.registerCacheManager(cm1, cm2);    
>>>  }
>>> 
>>>  @Test
>>>  void testMethod() {
>>>       datagridManager.cache(index).put(xx)
>>>       datagridManager.manager(index).getStatus()
>>>       datagridManager.tm(cache)...
>>>       ...
>>>  }
>>> }//TestClass
>>> 
>>> where the DatagridManager would be basically class with functionality of
>>> MultipleCacheManagersTest class (org.infinispan.core.test package).
>>> 
>>> I would basically copy the following classes to the new project and do
>>> some changes (removing all testng annotations etc.):
>> 
>> Why copy? Shouldn't they be migrated over? 
>> 
>> The problem with copying is that you're gonna have to keep them in sync which is a PITA, but maybe you're just seeing this as a 1st step?
> 
> What do you mean by "migrated over"?  ...Yes, it's a PITA to copy
> classes and keep them in sync. That's why I wrote the mail, I need to
> know others' opinion. Basically, what I need to do is to get rid of
> testng annotations in MultipleCacheManagersTest (or just suppress them)
> and remove its only abstract method because users will directly call
> this class' methods in order to create cluster of cache managers/caches
> (this will be done in a method annotated with @BeforeMethod/@Before). So
> maybe I could just create an "adapter" class for
> MultipleCacheManagersTest class (only the adapter would be maintained
> separate from ISPN source code). Need to think about it more, any
> suggestions welcome:)   
> 
> Another problem is that cluster initialization which is now done
> BeforeClass would have to be done in @BeforeMethod/@Before. This is
> because Arquillian doesn't support injecting objects into a test class
> before in @BeforeClass phase. I got to know this recently and it will
> mean tests will run longer. Would developers want to use such tool when
> only option is to initialize cluster before each method? 

Hmmm, that's not nice at all. It's pretty wasteful to start a CacheManager before each test with its JGroups channel....etc :(

In fact, I'm not seeing many (any?) benefits of integrating Arquillian, maybe you can refresh my memory? :)

> 
>> 
>>> 
>>> - AbstractCacheTest.java
>>> - AbstractInfinispanTest.java
>>> - MultipleCacheManagersTest.java (renamed to DatagridManager)
>>> 
>>> The project would depend on 
>>> infinispan-core-5.1.0.ALPHA2-tests.jar so all the other helper classes
>>> (being used from those mentioned above) would be downloaded with this
>>> jar.
>> 
>> I'd then expect the rest of modules to depend on the Infinispan Arquillian module/project, right?
> 
> Yes, right.
> 
>> 
>>> 
>>> This is because all these test classes are changing quite often so I'm
>>> trying to copy the smallest possible number of classes and leave the
>>> rest in infinispan-core. Later, when I want to update them, it will be
>>> just a matter of changing of 2-3 classes.
>>> 
>>> 
>>> What do you think about this approach?
>>> 
>>> 
>>> Thanks for each reply
>>> 
>>> 
>>> -- 
>>> Martin Gencur
>>> --
>>> JBoss QE, Enterprise Data Grid
>>> Desk phone: +420 532 294 192, ext. 62192
>>> 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> -- 
> Martin Gencur
> --
> JBoss QE, Enterprise Data Grid
> Desk phone: +420 532 294 192, ext. 62192
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache