Ivan R., Ivan P., thank you for the suggestions, I took a look at them. According to checking CacheAtomicityMode on null in IgniteCacheConfigVariationsAbstractTest#atomicityMode - are you sure that checking should proceed on test level? May be it will be better to make default cache value in case if cc.getAtomicityMode() == null in CacheConfiguration constructor [1]?
Also let me suggest one minor change according cache specification in IgniteCacheReadThroughEvictionSelfTest. The same logic is used in GridCacheAbstractSelfTest#cacheConfiguration [2]. I think we can excract this code block in a separate static methods (initCacheConfig, for example) in IgniteCacheReadThroughEvictionSelfTest and invoke it in IgniteCacheReadThroughEvictionSelfTest#variationConfig and GridCacheAbstractSelfTest#cacheConfiguration methods. In addition, I want to draw your attention to IgniteContinuousQueryConfigVariationsSuite test runs [3]. CacheContinuousQueryVariationsTest are generated dynamically. The first batch (12 tests) works fine, but on the next runs we got NPE in IgniteCacheConfigVariationsAbstractTest#afterTest - default cache does not exist and we can not invoke unwrap() on this [4]. Seems that the problem is in IgniteCacheConfigVariationsAbstractTest#beforeTestsStarted/afterTestsStopped methods, cache is not properly created (or already existed cache is destroyed). By the way, should I resolve these issues in the context of IGNITE-11708 or create a separate ticket(s)? [1] https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/CacheConfiguration.java#L434 [2] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/GridCacheAbstractSelfTest.java#L235 [3] https://ci.ignite.apache.org/viewLog.html?buildId=3701865&buildTypeId=IgniteTests24Java8_RunAllNightly [4] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L212 пт, 26 апр. 2019 г. в 18:01, Ivan Rakov <ivan.glu...@gmail.com>: > Ivan P., > > Good catch, thanks. > > I was wrong, test scenario is correct. The problem was in > atomicityMode() method - it could have returned null (which was okay for > config generation, but wasn't expected in the test code). > Please take a look at tx_out_test_fixed.patch (attached to > IGNITE-11708). To sum it up, both issues should be fixed now. > > Best Regards, > Ivan Rakov > > On 26.04.2019 14:40, Павлухин Иван wrote: > > Ivan R., > > > > As I can see IgniteCacheConfigVariationsFullApiTest#testGetOutTx does > > not expect lock/unlock events due to line: > > if (atomicityMode() == ATOMIC) > > return lockEvtCnt.get() == 0; > > > > Could you please elaborate? > > > > пт, 26 апр. 2019 г. в 13:32, Ivan Rakov <ivan.glu...@gmail.com>: > >> Ivan, > >> > >> Seems like IgniteCacheReadThroughEvictionSelfTest is broken. Test > >> scenario assumes that even after expiration entry will be present in > >> IgniteCache as per it will be loaded from CacheStore. However, > >> CacheStore is not specified in node config. I've added patch that > >> enables cache store factory, please check IGNITE-11708 attachments. > >> Regarding IgniteCacheConfigVariationsFullApiTest#testGetOutTx* tests: > >> from my point of view, test scenarios make no sense. We perform get() > >> operation from ATOMIC caches and expect that entries will be locked. I > >> don't understand why we should lock entries on ATOMIC get, therefore I > >> suppose to remove part of code where we listen and check > >> EVT_CACHE_OBJECT_LOCKED/UNLOCKED events. > >> > >> Best Regards, > >> Ivan Rakov > >> > >> On 17.04.2019 22:05, Ivan Rakov wrote: > >>> Hi Ivan, > >>> > >>> I've checked your branch. Seems like these tests fail due to real > >>> issue in functionality. > >>> I'll take a look. > >>> > >>> Best Regards, > >>> Ivan Rakov > >>> > >>> On 17.04.2019 13:54, Ivan Fedotov wrote: > >>>> Hi, Igniters! > >>>> > >>>> During work on iep-30[1] I discovered that > >>>> IgniteConfigVariationsAbstractTest subclasses - it is about 15_000 > >>>> tests[2] > >>>> - do not work. > >>>> You can check it just run one of the tests with log output, for > example > >>>> ConfigVariationsTestSuiteBuilderTest#LegacyLifecycleTest#test1 [3]. > >>>> There is no warning notification in the console. The same situation > with > >>>> other IgniteConfigVariationsAbstractTest subclasses - tests run, but > >>>> they > >>>> simply represent empty code. > >>>> > >>>> So, I created a ticket on such issue [4] and it turned out that the > >>>> problem > >>>> is with ruleChain in IgniteConfigVariationsAbstractTest [5]. > >>>> The rule that is responsible for running a test statement does not > start > >>>> indeed [6] under ruleChain runRule. I suggested a solution - move > >>>> testsCfg > >>>> initialization to > >>>> IgniteConfigVariationsAbstractTest#beforeTestsStarted method. After > such > >>>> changes ruleChain becomes not necessary. > >>>> > >>>> But I faced another problem - multiple failures on TeamCity [7]. From > >>>> logs, > >>>> it seems that failures are related to what tests check, but not JUnit > >>>> error. > >>>> I can not track TeamCity history on that fact were tests failed or > >>>> not on > >>>> the previous JUnit version - the oldest log is dated the start of the > >>>> March > >>>> when JUnit4 > >>>> already was implemented (for example, this [8] test). > >>>> Moreover, there are not so much failed tests, but because of running > >>>> with > >>>> multiple configurations > >>>> (InterceptorCacheConfigVariationsFullApiTestSuite_0 > >>>> ..._95) it turns out about 400 failed tests. TeamCity results also > >>>> confirm > >>>> that tests do not work in the master branch - duration time is less > than > >>>> 1ms. Now all tests are green and that is not surprising - under @Test > >>>> annotation, nothing happens. > >>>> > >>>> Could some of us confirm or disprove my guess that tests are red > >>>> because of > >>>> its functionality, but not JUnit implementation? > >>>> And if it is true, how should I take such fact into account in this > >>>> ticket? > >>>> > >>>> [1] > >>>> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5 > >>>> > >>>> [2] > >>>> > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testsuites/InterceptorCacheConfigVariationsFullApiTestSuite.java > >>>> > >>>> [3] > >>>> > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/test/ConfigVariationsTestSuiteBuilderTest.java#L434 > >>>> > >>>> [4] https://issues.apache.org/jira/browse/IGNITE-11708 > >>>> [5] > >>>> > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62 > >>>> > >>>> [6] > >>>> > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java#L181 > >>>> > >>>> [7] > >>>> > https://mtcga.gridgain.com/pr.html?serverId=apache&suiteId=IgniteTests24Java8_RunAll&branchForTc=pull/6434/head&action=Latest > >>>> > >>>> [8] > >>>> > https://ci.ignite.apache.org/project.html?tab=testDetails&projectId=IgniteTests24Java8&testNameId=-9037806478172035481&page=8 > >>>> > >>>> > > > > > -- Ivan Fedotov. ivanan...@gmail.com
