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@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@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@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@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev