[infinispan-dev] Creating cache managers in your unit tests

[Sanne Grinovero]

I've found that still some tests are not properly killing the
CacheManager, making other random tests fail,
so I wrote an extension to Infinispan's TestNG listener to identify
the guilty implementations.

I opened ISPN-323 to track this.

To identify a non-cleaning test the testNG listener will create a new
CacheManager and verify the number of members,
so this is slowing down tests; to not annoy you it's only enabled in a
new profile "debug-tests":

mvn -Pdebug-tests clean test

Also keep in mind that, being a listener, it can't make the test fail:
to find the tests you'll have to grep the build output
for "CacheManagers alive after test!".

We still need to fix the identified tests, I'll create subtasks of
ISPN-323 for that.

Cheers,
Sanne


2009/12/29 Sanne Grinovero <sanne.grinovero at gmail.com>:
> Thanks for looking into this, I was a bit worried about the testsuite
> as I'm still unable to build properly.
>
> The ChannelLookupTest mentioned before was always failing because the
> testsuite was overriding the setTransportProperties,
> I've changed the TestCacheManagerFactory.createCacheManager to add
> transport properties instead of replacing them,
> fixing the test.
>
> I'm down to 1 build error now:
> Failed tests:
>  testTransactional(org.infinispan.distribution.rehash.ConcurrentJoinTest)
>
> Tests run: 686, Failures: 1, Errors: 0, Skipped: 0
>
> Cheers,
> Sanne
>
> 2009/12/29 Vladimir Blagojevic <vblagoje at redhat.com>:
>> The main problem remains unresolved: creating cache managers, using
>> them, and not cleaning up. Have a look at ChannelLookupTest. Are you
>> familiar with this one :)?
>>
>>
>> On 09-12-24 3:18 PM, Manik Surtani wrote:
>>> Guys,
>>>
>>> as far as possible, please extend either SingleCacheManagerTest [1] or MultipleCacheManagersTest [2]. and use the corresponding helper methods there to create a new CacheManager.  Alternatively, if you have a unit test that needs to create its own CacheManager directly, please use TestCacheManagerFactory [3].  Do *not* use "new DefaultCacheManager()" directly since this means the framework does not have a chance to alter config settings to work within the framework, including clustering settings to make sure the test does not interfere with other tests, threadpool settings to prevent unnecessary OOMs when running the entire suite with thousands of cache managers, etc.
>>>
>>> I have just fixed a bunch of offending tests [4], and updated the wiki page [5] on writing tests accordingly.  Please follow these guidelines.
>>>
>>> Cheers&  Happy X'mas!
>>> Manik
>>>
>>> [1] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/test/java/org/infinispan/test/SingleCacheManagerTest.java?r=1216
>>> [2] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/test/java/org/infinispan/test/MultipleCacheManagersTest.java?r=1216
>>> [3] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/test/java/org/infinispan/test/fwk/TestCacheManagerFactory.java?r=1327
>>> [4] http://fisheye.jboss.org/changelog/Infinispan/trunk?cs=1327
>>> [5] http://community.jboss.org/wiki/ParallelTestSuite
>>>
>>>
>>> --
>>> Manik Surtani
>>> manik at jboss.org
>>> Lead, Infinispan
>>> Lead, JBoss Cache
>>> http://www.infinispan.org
>>> http://www.jbosscache.org
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>