User development, The document "WritingUnitTestsForJBossCache ", was updated Feb 22, 2010 by Manik Surtani.
To view the document, visit: http://community.jboss.org/docs/DOC-13315#cf Document: -------------------------------------------------------------- > *NOTE* See http://community.jboss.org/docs/DOC-13470for a guide to writing > unit tests for http://www.infinispan.org. > http://www.jboss.org/files/jbosslabs/design/infinispan/logo/images/infinispan_logo_200px.png JBossCache now runs the unit test suite in parallel. The benefit of this is reduction of execution suite execution time from 2 hours + down to about 6-7 mins (10 threads). Threads are constraints and best practices that need to be followed in order to ensure correctness and keep the execution time to a min. This page describe all the practices needed for adding new tests, or maintaining existing ones. 1. Each test class *MUST* have an unique test name. The testing framework is configured to run all test having the same name in the same thread. This ensures that all the methods of the class are being runned sequentially, by same thread. No synchronization on test state (fixture) is needed. As a connvention, the name of the test should be: for test class org.jboss.cache.mypackage.MyTest the name is be "mypackage.MyTest". This is guarantees uniqueness. 2. For test using replicated caches, it is *mandatory* to use one of the +UnitTestCacheFactory.createCache+ methods.This will mangle the underlaying jgroups configuration, making sure that the caches you create do not interfere with caches created by different threads. Also, the +Configuration+ object passed to +UnitTestCacheFactory.createCache+ *must* be obtained through +UnitTestConfigurationFactory.createConfiguration+. Warning: do not instantiate +Configuration only+ objects directly unless absolutely necesarelly (like for testing the Configuration object itself). 3. Increase test performance. This is in order to have a short running suite. The main performance fault when writing unit tests comes from frequent instantiation of caches, especially for large clusters. A way too reduced the number of caches insances is through usage of @BeforeClass annotation, rather than the classic JUnit-like @BeforeMethod: the caches are being created only once for test class, rather than before each test method. Of course, between test methods you'll have to take care of cleaning up cache content, so that new test can run on a pristine cache. There are two utility classes you can use: +AbstractSingleCacheTest+ and +AbstractMultipleCachesTest+. These tests might be extended to support single cluster creation for all tests, also taking care of cache cleanup between test methods. 4. *DON'T* rely on Thread.sleep(). When running in heavily threaded environemnts this will most often not work. E.g. if ASYNC_REPL, don't do a sleep(someValue) and expect the data will be replicated to anoter cache instance after that. For this, you should rather use +ReplicationListener+s (check javadoc). Generally speaking, if you expect something will happen and you don't have a gurantee when, a good approach is to try that expectation in a loop, several times, with an generous (5-10secs) timeout. E.g. while (Systet.currentTimeMillis() - startTime < timeout) { if (conditionMeet()) break; Thread.sleep(50); } 5. Even though we've tried to reduce them to a min, intermittent failures might still appear from time to time. If you see such failures *in existing code* please report them jboss dev mailing list. + + --------------------------------------------------------------
_______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
