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

Issue #14019: Kill mutation for setSeverity in Checker #14462

Merged
merged 1 commit into from
Mar 12, 2024

Conversation

Zopsss
Copy link
Contributor

@Zopsss Zopsss commented Feb 11, 2024

Issue #14019 Kill mutation for setSeverity in checker

created a test case to kill the mutation

@Zopsss Zopsss force-pushed the checker branch 2 times, most recently from 6d8e4b6 to b3abaa1 Compare February 11, 2024 18:51
@Zopsss Zopsss marked this pull request as ready for review February 11, 2024 19:10
Copy link
Member

@romani romani left a comment

Choose a reason for hiding this comment

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

Very good, minor changes:

@Zopsss
Copy link
Contributor Author

Zopsss commented Feb 12, 2024

⚠️ Failed to start an instance: FAILED_PRECONDITION: Monthly compute limit exceeded!

Cirrus is failing

Copy link
Member

@romani romani left a comment

Choose a reason for hiding this comment

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

Items

Copy link
Member

@romani romani left a comment

Choose a reason for hiding this comment

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

last minor:

Copy link
Member

@romani romani left a comment

Choose a reason for hiding this comment

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

items:

Copy link
Member

@romani romani left a comment

Choose a reason for hiding this comment

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

ok to merge if CI pass

@Zopsss
Copy link
Contributor Author

Zopsss commented Feb 17, 2024

ok to merge if CI pass

no this is not okay, the test case should be failing after mutation please check this comment #14462 (comment)

@romani
Copy link
Member

romani commented Feb 17, 2024

mutatedClass com.puppycrawl.tools.checkstyle.Checker

so you need to set property in Checker not in LineLength.
Play with:

<module name="Checker">
  <property name="severity" value="ignore"/>

@Zopsss
Copy link
Contributor Author

Zopsss commented Feb 18, 2024

mutatedClass com.puppycrawl.tools.checkstyle.Checker

so you need to set property in Checker not in LineLength. Play with:

<module name="Checker">
  <property name="severity" value="ignore"/>

did this but it is still giving the same result, the test case is still passing even after mutation. Pushed the changes for you to review it. The test case was giving violation on line 11 after I set the severity property to Checker instead of LineLength

@Zopsss
Copy link
Contributor Author

Zopsss commented Feb 19, 2024

@romani ping

@Zopsss Zopsss force-pushed the checker branch 2 times, most recently from cceaed1 to 2800511 Compare February 20, 2024 07:21
@Zopsss
Copy link
Contributor Author

Zopsss commented Feb 20, 2024

I tried debugging the code and found that createConfiguration() method used inside verifyWithInlineConfigParser() is not generating proper config. It is not adding the severity property to the Checker module. Then verifyViolations() method is using that inappropriate config to check the violation. We're expecting that there will be no violation as we have added the severity property and set it to ignore but the createConfiguration() is generating the config without severity property and it is expecting violation on line 11. That's why our test case is failing. I have attached the config's ss generated by createConfiguration() below:

Screenshot (269)

the propertyMap should have severity property set to ignore but it contains only charset property. Should we go back to using verify() method or is there a solution available to fix this?

@romani
Copy link
Member

romani commented Feb 20, 2024

lets try to move forward and fix code to make in-memory config to be correct (what we expect).

@Zopsss
Copy link
Contributor Author

Zopsss commented Feb 20, 2024

lets try to move forward and fix code to make in-memory config to be correct (what we expect).

Can you explain me what do you mean by in-memory config? Do you mean the config created by createConfiguration()?

@romani
Copy link
Member

romani commented Feb 20, 2024

Do you mean the config created by createConfiguration()?

Yes.

You can fix problem in this method in this PR, looks like it is first time we use config like this, do it will be natural to see it here and immediately use it in Input.

@Zopsss
Copy link
Contributor Author

Zopsss commented Feb 20, 2024

Do you mean the config created by createConfiguration()?

Yes.

You can fix problem in this method in this PR, looks like it is first time we use config like this, do it will be natural to see it here and immediately use it in Input.

Ohkay and should I keep it in seperate commit?

@romani
Copy link
Member

romani commented Feb 21, 2024

in same commit is ok.

@Zopsss Zopsss force-pushed the checker branch 3 times, most recently from 8bcc43d to e71b610 Compare February 24, 2024 09:34
@Zopsss
Copy link
Contributor Author

Zopsss commented Feb 24, 2024

fixed a small bug in createConfiguration(), now our test case is passing and when we mutate the code it is failing as expected.

Reason behind making new createConfiguration():

the regular createConfiguration() does not checks for the global properties, to check for the global properties we needed the whole xml config to see if it contains any global properties before any child modules, for this I created a new createConfiguration() which takes filePath as a parameter. With the help of filePath we can get the whole xml config, after getting it I ran a loop to check if it contains any global properties before starting a new child module, if it does then we add it to the root config, after checking the the xml config we call the regular createConfiguration() method which generates the config with global properties available to it.

I could also modify the current createConfiguration() method to check for global properties but then I will also need to update all the caller methods of it and it might cause some unexpected behaviour, so I thought it would be more reliable to use the new createConfiguration() method.

And also I'm sorry this is taking longer than I expected, I was little bit busy with college stuff....

@Zopsss
Copy link
Contributor Author

Zopsss commented Feb 26, 2024

@romani

@romani
Copy link
Member

romani commented Feb 27, 2024

This is not good, we should reuse existing parser. I can not help on the go, I need big screen time to find solution and guide you. It would be good if you find solution your self

@@ -247,7 +247,7 @@ inputSource, new PropertiesExpander(System.getProperties()),
throw new CheckstyleException(
"First module should be Checker, but was " + configName);
}
handleXmlConfig(testInputConfigBuilder, inputFilePath, xmlConfig.getChildren());
handleXmlConfig(testInputConfigBuilder, inputFilePath, xmlConfig);
Copy link
Contributor Author

@Zopsss Zopsss Feb 29, 2024

Choose a reason for hiding this comment

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

removed the getChildren() so that we can also set the properties of Checker module to the testInputConfigBuilder instead of directly setting the children module's properites. By adding Checker's properties to the testInputConfigBuilder, we can access it from childrenModules declared in the TestInputConfiguration.java


if ("Checker".equals(moduleName)) {
handleXmlConfig(testInputConfigBuilder, inputFilePath, module.getChildren());
}
Copy link
Contributor Author

@Zopsss Zopsss Feb 29, 2024

Choose a reason for hiding this comment

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

if the current module is Checker then we're recursively calling the handleXmlConfig() method to set properties of Checker's children modules, this way the testInputConfigBuilder will contain Checker properties as well as Checker's children modules' properties.

Copy link
Member

Choose a reason for hiding this comment

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

it is weird that if ("Checker".equals(moduleName)) { is below of if ("TreeWalker".equals(moduleName)) {
but it is better to fix it at new PR, here is new issue on this - #14653


childrenModules.remove(checkerConfig);
}

Copy link
Contributor Author

@Zopsss Zopsss Feb 29, 2024

Choose a reason for hiding this comment

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

This code checks if the childrenModules contains Checker's properties? if yes then add those properties to the root config and remove the Checker properties' object from childrenModules as we don't need it anymore

@Zopsss
Copy link
Contributor Author

Zopsss commented Feb 29, 2024

@romani I tried different approach this time, I need your opinion on this. Is it okay or do we need to change something? The test case is passing and after mutating the code it is failing as we expected.

@Zopsss
Copy link
Contributor Author

Zopsss commented Mar 1, 2024

CircleCI is complaining, idk why though

@@ -320,6 +324,9 @@ private static String getFullyQualifiedClassName(String filePath, String moduleN
"com.puppycrawl.tools.checkstyle.checks.javadoc.SummaryJavadocCheck");
moduleMappings.put("LineLength",
"com.puppycrawl.tools.checkstyle.checks.sizes.LineLengthCheck");
moduleMappings.put("Checker",
"com.puppycrawl.tools.checkstyle.CheckerCheck");

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Had to add Checker here, cuz some tests started throwing an error something like:

config comment is not defined properly

@Zopsss
Copy link
Contributor Author

Zopsss commented Mar 8, 2024

@romani ping

resolved the merge conflicts. I've made comments explaining the changes, let me know if this is the correct way to enable the verifyWithInlineConfigParser() to check for the global properties ( Checker module's properties ) or not.

@Zopsss
Copy link
Contributor Author

Zopsss commented Mar 12, 2024

@romani

Copy link
Member

@romani romani left a comment

Choose a reason for hiding this comment

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

I confirming that we can not do better solution for now, more refactoring is required.
#14653

but this will unblock all PRs that planning to use Checkers/Treewalker in their tests.

@romani romani merged commit 2c00d23 into checkstyle:master Mar 12, 2024
113 checks passed
@Zopsss Zopsss deleted the checker branch March 14, 2024 10:42
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

3 participants