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