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 #12586: Optimize testing methods to run check one time over a file #14588

Merged
merged 1 commit into from May 10, 2024

Conversation

mahfouz72
Copy link
Member

@mahfouz72 mahfouz72 commented Mar 2, 2024

First step for #12586:

this is not the final fix I just want to make sure that I am on the right direction also I faced some errors want to discuss them. IMO once this optimization is completed and reaches its final form, it will provide significant benefits. specifically aims to improve the process of mvn test and mvn clean verify.

Comment on lines 238 to 261
verifyViolations(parsedConfig, filePath, testInputConfiguration.getViolations());
verify(parsedConfig, filePath, expected);
final List<String> actualViolations = getActualViolationsForFile(parsedConfig, filePath);
verifyViolations(filePath, testInputConfiguration.getViolations(), actualViolations);

assertWithMessage("Violations for %s differ.", filePath)
.that(actualViolations)
.containsExactlyElementsIn(expected);
Copy link
Member Author

Choose a reason for hiding this comment

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

Instead of running a check twice. once to verify the violation in verifyViolations() against testInputConfigurationViolation that got parsed from the input file. and another one with verify() to verify violations against the expected array.

I extracted running the check out to getActualViolationsForFile() once and then used these actualViolations to verify them against the testInputConfigurationViolation with verifyViolations() and then verify them with the expected array with assertion

Comment on lines 503 to 559
private void verifyViolations(String file,
List<TestInputViolation> testInputViolations,
List<String> actualViolations) {
final List<Integer> actualViolationLines = actualViolations.stream()
.map(violation -> violation.substring(0, violation.indexOf(':')))
.map(Integer::valueOf)
.collect(Collectors.toUnmodifiableList());
final List<Integer> expectedViolationLines = testInputViolations.stream()
.map(TestInputViolation::getLineNo)
.collect(Collectors.toUnmodifiableList());
assertWithMessage("Violation lines for %s differ.", file)
.that(actualViolationLines)
.isEqualTo(expectedViolationLines);
for (int index = 0; index < actualViolations.size(); index++) {
assertWithMessage("Actual and expected violations differ.")
.that(actualViolations.get(index))
.matches(testInputViolations.get(index).toRegex());
}
}
Copy link
Member Author

@mahfouz72 mahfouz72 Mar 2, 2024

Choose a reason for hiding this comment

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

this method is not supposed to be here at the final fix . I just overloaded the normal verifyViolation method to test my new changes. but the other remaining test methods still use the old verifyViolation So I just did that to make the old tests method work but at the end of the fix it should be only one verifyViolation method

@@ -188,6 +188,7 @@ public void testWriteTagRecordsAndCompactCtors() throws Exception {
getNonCompilablePath("InputWriteTagRecordsAndCompactCtors.java"), expected);
}


@Override
protected void verify(Checker checker,
File[] processedFiles,
Copy link
Member Author

@mahfouz72 mahfouz72 Mar 2, 2024

Choose a reason for hiding this comment

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

some of these tests here are not passing because it was using an overridden verify method not the normal one in the abstractTestSupport. any guidance on how to solve this will be helpful

getActualViolationForFile that I used above is returning empty array and not detecting the violation in input files of WriteTagCheckTest

Copy link
Member

Choose a reason for hiding this comment

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

I am not an expert on this part of the code, but you may find it useful to look back through git blame to see why these tests are different than others, and investigate the possibility of migrating the tests that deviate to the normal verify methods. In fact, this may even be some prework that you could do before solving this issue.

Copy link
Member Author

@mahfouz72 mahfouz72 Mar 4, 2024

Choose a reason for hiding this comment

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

@nrmancuso I looked in git blame didn't help much. but I think that the reason this test is different is that the default severity for this check is info so the getViolationForFile() is returning an empty array ( I am not sure please confirm that) . so this verify uses the output stream to test with it not the actual violation returned from the file

Copy link
Member Author

@mahfouz72 mahfouz72 Mar 4, 2024

Choose a reason for hiding this comment

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

is migrating back to use verify instead of verifyWithInlineConfigParser for this test only will be a valid solution

@mahfouz72 mahfouz72 changed the title Issue #12586: Optimize testing methods to run check on time on a file Issue #12586: Optimize testing methods to run check one time over a file Mar 2, 2024
@mahfouz72
Copy link
Member Author

tried to override verifyWithInlineConfigParser() to use the old way of testing but got error as usage of verify is forbbeden

forbidden method invocation: com.puppycrawl.tools.checkstyle.AbstractModuleTestSupport#verify(com.puppycrawl.tools.checkstyle.api.Configuration, java.lang.String, java.lang.String[]) [Use inline config parser instead.]
[ERROR]   in com.puppycrawl.tools.checkstyle.checks.javadoc.WriteTagCheckTest

@romani
Copy link
Member

romani commented Mar 5, 2024

We just need to reuse existing method in final fix. During transition to final state we can suppress such violation

@mahfouz72 mahfouz72 force-pushed the issue-12586-optimizetests branch 4 times, most recently from 79f130e to cb3f403 Compare March 5, 2024 10:56
@nrmancuso
Copy link
Member

@mahfouz72 where are we at here? Can we assist?

@mahfouz72
Copy link
Member Author

mahfouz72 commented Mar 16, 2024

@nrmancuso I just need time to get back to this PR to figure out why there are surviving mutations and how to kill them. it would be helpful If you could review my changes and tell me if there is something that is not correct and is the reason for all those survivals

@romani
Copy link
Member

romani commented Mar 16, 2024

This means that we actually used double execution to kill mutation :).
We can execute some tests twice to kill them again :).

@mahfouz72 mahfouz72 force-pushed the issue-12586-optimizetests branch 2 times, most recently from 2859568 to 752d20b Compare March 16, 2024 12:36
@mahfouz72
Copy link
Member Author

@romani I optimized one test only and still got survivals I don't why we still have tests that execute check twice

@mahfouz72
Copy link
Member Author

@romani do you have idea why this happened? .I debugged and we didn't change the logic of testing at all the logic still the same we now just run the checker one time why we got this survivals?

@romani
Copy link
Member

romani commented May 8, 2024

Let's be not fanatic about to convert all at ones, keep treewalker on double run method for now. In next step/PR we will reduce double run to few tests methods, and may be we will keep such few test methods on double run.

Create verify method that kept old behavior of double run, and use it to satisfy pitest.

@mahfouz72 mahfouz72 force-pushed the issue-12586-optimizetests branch 5 times, most recently from 41ee4a3 to d26b0d9 Compare May 8, 2024 18:38
@mahfouz72
Copy link
Member Author

@romani Please review I kept tree walker tests on double run to satisfy pitest
I also kept writeTagCheckTest on double run due to #14588 (comment)
In the next PR, we can fix other verify methods

@romani
Copy link
Member

romani commented May 9, 2024

@mahfouz72
Copy link
Member Author

@romani done can you please explain to me why we should make the method static and no warnings on other methods?
6034763

@romani
Copy link
Member

romani commented May 9, 2024

static modifier is kind of synonym to "state less" method, so does not depends on class fields, so can be used anywhere and does no side effects and simply return you a value based on parameters.

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.

in next PRs we will try to minimize usage of double execution in other test methods.

Copy link
Member

@nrmancuso nrmancuso left a comment

Choose a reason for hiding this comment

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

Items:

@nrmancuso nrmancuso merged commit c34d756 into checkstyle:master May 10, 2024
114 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants