Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IGNITE-11708 "Unable to run tests in IgniteConfigVariationsAbstractTest subclasses" #6434

Closed
wants to merge 19 commits into from
Closed

Conversation

lvanan
Copy link
Contributor

@lvanan lvanan commented Apr 10, 2019

No description provided.

@@ -108,9 +92,17 @@ protected static void injectTestsConfiguration(VariationsTestsConfig testsCfgInj
return false;
}

/** Check that test name is not null. */
@Before
public void checkTestName(){
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the purpose of that check? Is it specific and necessary for IgniteConfigVariationsAbstractTest?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left it from the previous code. Such check already exists in GridAbstractTest [1].
During run IgniteConfigVariationsAbstractTest subclasses, I did not catch this assertion. But maybe it exists a specific case in which check is necessary.
[1] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java#L188

@@ -108,9 +92,17 @@ protected static void injectTestsConfiguration(VariationsTestsConfig testsCfgInj
return false;
}

/** Check that test name is not null. */
@Before
public void checkTestName(){
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also space is missing before {.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

assert testsCfg != null;
assert testsCfgInjected != null;

testsCfg = testsCfgInjected;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now testsCfg is assigned before all tests in a class. Before that change it was assigned before each test method execution. Could you please explain why it still works as expected?

Copy link
Contributor Author

@lvanan lvanan May 20, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as I see testsCfg do not change during test methods execution. So the reason for me was to remove unnecessary initialization.
But I can try to move such initialization to beforeTest() method in IgniteConfigVariationsAbstractTest class to leave the same logic as it was before.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean that we inject TestConfigurations only once [1] and I do not see a reason to re-initialize testCfg before each method.
[1] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/test/ConfigVariationsTestSuiteBuilderTest.java#L401

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@1vanan I suppose it is expected to work as follows:

  1. Test classes are created using a code generation library.
  2. testsCfgInjected (static member) is assigned on @BeforeClass level.
  3. testsCfg (instance member) is assigned on @Before level.

A test class instance is created for each test method execution. So, I do not understand how an expected configuration is injected to each test instance. Could you please that configurations are injected as expected? I suspect that dummyCfg is injected everywhere now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pavlukhin you are definitely right.
Please check the last commit - I inserted [1] debug info for checking testCfg. When we assign testsCfgInjected before test class, it returns "Dummy config", before each test - another cfg description.
So I think to remain the last version (in the last commit) - in beforeTest method.
[1] https://github.com/apache/ignite/pull/6434/files#diff-78ef107e580c29ced70d7eb0739f2c7bR147


/** Executes after test class. Checks that {@link #testCheck()} method was executed indeed. */
@AfterClass
public static void validatetestExecution(){
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

space before {

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done


/** JUnit test method. */
@Test
public void testCheck(){
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

space before {

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@@ -60,12 +61,12 @@

/** */
@RunWith(IgniteContinuousQueryConfigVariationsSuite.SuiteSingleNode.class)
public static class SingleNodeTest {
@Ignore("https://issues.apache.org/jira/browse/IGNITE-11851") public static class SingleNodeTest {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose @Ignore should be placed on a separate line according to our conventions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

}

/** */
@RunWith(IgniteContinuousQueryConfigVariationsSuite.SuiteMultiNode.class)
public static class MultiNodeTest {
@Ignore("https://issues.apache.org/jira/browse/IGNITE-11851") public static class MultiNodeTest {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose @Ignore should be placed on a separate line.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@@ -144,6 +144,7 @@ public void testKeyAffinityDeploy() throws Exception {
*/
@Test
public void testMultipleDeploy() throws Exception {
System.out.println("~~! " + testsCfg.description());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest to use GridAbstractTest.info here (if this output is really needed).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pavlukhin No, it is just to debug in the context of testsCfg question.
I'll remove it in the next commit.

@@ -92,22 +73,17 @@
@Override public String getTestIgniteInstanceName() {
return "testGrid";
}

/**
* Invoked by reflection from {@code ConfigVariationsTestSuiteBuilder}.
Copy link
Contributor

@pavlukhin pavlukhin May 30, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that we can add a comment to testsCfg fields stating that it is assigned by generated code. Otherwise it is not clear how and where is it assigned making it hard to understand by future maintainers.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I paid attention to this moment in comments

@asfgit asfgit closed this in 18126a8 Jun 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants