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

Parallelize coverage analysis in CoveredTestResultPerTestMethod #112

Merged

Conversation

andre15silva
Copy link
Contributor

Running the jacoco analyzer is an expensive operation.

Unfortunately, jacoco doesn't provide a way of doing an analysis of several executions at once, which is why test-runner needs to analyze them separately.

This PR introduces parallelism in that stage, moving analysis from the end of each test case to the end of the entire test suite and running it inside of a parallel stream.

Running flacoco with this modification on math70 on my PC (4 cores) reduced the execution time by around 40%.

@andre15silva andre15silva force-pushed the paralellize-covered-test-result branch from 1eeb5e1 to b444b74 Compare August 4, 2021 13:34
@coveralls
Copy link

coveralls commented Aug 4, 2021

Pull Request Test Coverage Report for Build 1100800272

  • 46 of 53 (86.79%) changed or added relevant lines in 11 files are covered.
  • 5 unchanged lines in 4 files lost coverage.
  • Overall coverage increased (+0.6%) to 45.401%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/main/java/eu/stamp_project/testrunner/listener/utils/ListenerUtils.java 8 9 88.89%
src/main/java/eu/stamp_project/testrunner/runner/coverage/JUnit5JacocoRunnerPerTestMethod.java 0 1 0.0%
src/main/java/eu/stamp_project/testrunner/listener/junit5/CoveragePerJUnit5TestMethod.java 0 5 0.0%
Files with Coverage Reduction New Missed Lines %
src/main/java/eu/stamp_project/testrunner/listener/impl/CoveragePerTestMethodImpl.java 1 84.0%
src/main/java/eu/stamp_project/testrunner/listener/junit5/CoveragePerJUnit5TestMethod.java 1 0%
src/main/java/eu/stamp_project/testrunner/runner/coverage/JUnit5JacocoRunnerPerTestMethod.java 1 0%
src/main/java/eu/stamp_project/testrunner/listener/impl/CoveredTestResultPerTestMethodImpl.java 2 73.75%
Totals Coverage Status
Change from base Build 1044521416: 0.6%
Covered Lines: 1086
Relevant Lines: 2392

💛 - Coveralls

Copy link
Member

@danglotb danglotb left a comment

Choose a reason for hiding this comment

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

LGTM. Thank you very much!

Only the code duplication is a bit frustrating, but I do not see another way.

Could we put the following code:

// We need to clone each result so it doesn't get changed by the runtime afterwards
ExecutionDataStore executionDataStore = new ExecutionDataStore();
			this.internalCoveredTestResult.getExecutionData().getContents().stream().forEach(x -> {
	ExecutionData executionData = new ExecutionData(x.getId(), x.getName(), x.getProbes().clone());
	synchronized (executionDataStore) {
		executionDataStore.put(executionData);
	}
});
this.internalCoveredTestResult.getExecutionDataStoreMap().put(
	this.toString.apply(testIdentifier),
	executionDataStore
);

In a "Utils" class, in order to avoid the duplication? Like something:

public static void cloneAndAddExecutionDataStore(CoveredTestResultPerTestMethod internalCoveredTestResult, Function<Description, String) toString) {
	// We need to clone each result so it doesn't get changed by the runtime afterwards
	ExecutionDataStore executionDataStore = new ExecutionDataStore();
	internalCoveredTestResult.getExecutionData().getContents().stream().forEach(x -> {
		ExecutionData executionData = new ExecutionData(x.getId(), x.getName(), x.getProbes().clone());
		synchronized (executionDataStore) {
			executionDataStore.put(executionData);
		}
	});
	internalCoveredTestResult.getExecutionDataStoreMap().put(
		toString.apply(description),
		executionDataStore
	);
}

Signed-off-by: André Silva <[email protected]>
@andre15silva
Copy link
Contributor Author

Hi @danglotb ,

Yes, for sure. I moved the cloning into an Utils class, but not the insertion since they are different implementation classes.

@danglotb danglotb merged commit 84c85fa into STAMP-project:master Aug 5, 2021
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.

3 participants