Igniters,
I created corresponding tickets [1][2][3][4] in Jira and outlined
description of problems in a nutshell. In the context of the current ticket
(IGNITE-11708), I ignored them.
If some of us have a comprehension of the problem why tests are failed,
please let know here or in the tickets.
Hi Igniters!
I found the solution for how to run IgniteConfigVariationsAbstractTest. I
removed garbage injection [1] and static variable [2].
Now assigning of VariationsTestsConfig proceeds in constructor class which
is created dynamically [3].
But I faced with the problem that a certain amount
Ivan F.,
Agree with referring tickets in @Ignore annotation.
Currently I have no access to a computer. Will be able to look at updated PR
next week.
Sent from my iPhone
> On 14 May 2019, at 10:55, Ivan Fedotov wrote:
>
> Ivan P.,
> I managed with IgniteConfigVariationsAbstractTest - now
Ivan P.,
I managed with IgniteConfigVariationsAbstractTest - now subclasses enable
[1].
I ignored all the failed tests that were mentioned in our conversation. If
you don't mind, I can create appropriate tickets and mention them in Ignore
annotation.
[1]
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 :
>
> Ivan R.,
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
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).
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,
>
> Seems like
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
Hi Dmitry,
Maybe if it will turn out that all tests fail because of functionality we
should ignore or mute these tests in the context of the ticket IGNITE-11708?
ср, 17 апр. 2019 г. в 23:20, Dmitriy Pavlov :
> Hi Ivan F.
>
> Thank you for finding it and bringing it here.
>
> Please feel free to
Hi Ivan F.
Thank you for finding it and bringing it here.
Please feel free to fix test to run (and fail) if the code it tests is
faulty now. If the community knows the moment when tests run will be
enabled, it is absolutely not an issue, that TeamCity Bot will complain
about new failures. I
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
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
13 matches
Mail list logo
