[infinispan-dev] ISPN-ARQUILLIAN - embedded mode

Tue Sep 27 03:17:39 EDT 2011

On Tue, 2011-09-27 at 09:11 +0200, Galder Zamarreño wrote:
> 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? :)
> 

I thought that. You can find the listing of benefits in
http://community.jboss.org/message/551784 (Aslak's reply). Not sure this
can convince you to use it in infinispan-core, though.

> > 
> >> 
> >>> 
> >>> - 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
> 
> 
> _______________________________________________
> 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