Ivan F., I think that it is better to enable IgniteConfigVariationsAbstractTest subclasses first, so no new broken tests will appear. After that we can fix IgniteConfigVariationsAbstractTest subclasses one by one in separate ticket(s).
вт, 30 апр. 2019 г. в 13:23, Ivan Fedotov <ivanan...@gmail.com>: > > 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 -- Best regards, Ivan Pavlukhin
