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

pitest: increase mutation coverage for pitest-checkstyle-filters profile to 100% #4396

Closed
Nimfadora opened this Issue May 31, 2017 · 2 comments

Comments

Projects
2 participants
@Nimfadora
Contributor

Nimfadora commented May 31, 2017

We created pitest profiles for non-checks code in #4367. Currently, we should increase coverage for pitest-checkstyle-filters profile up to 100%.
This issue is a subtask of #3708

Current threshold of pitest-checkstyle-filters profile: 95

@romani

This comment has been minimized.

Show comment
Hide comment
@romani

romani Jul 7, 2017

Member

@Nimfadora ,

It might be reasonable to split api from filters. Filters are like Checks, their logic is not used by others.
It will help us quickly cover filters as 100% as there is one GSoC project is focused on filter implementation.

from coverage report:

SuppressionsLoader.java// suppress.setModuleId(modId);

just run loader on config that have module with "id", example - https://github.com/checkstyle/checkstyle/blob/master/config/checkstyle_checks.xml#L57

SuppressionCommentFilter.java// ..... all cases

please play through accept(AuditEvent event) method to cover them.

SuppressWithNearbyCommentFilter.java// ..... all cases

please play through accept(AuditEvent event) method to cover them.

=============================

For all API code it is OK to use pure Unit Tests and ok to use reflection to check inner state of objects.
Reason: most of coverage is done by our functional test for sure, but we can not run pitest on whole project, so pure(probably ugly by reflection usage) tests is OK.

Member

romani commented Jul 7, 2017

@Nimfadora ,

It might be reasonable to split api from filters. Filters are like Checks, their logic is not used by others.
It will help us quickly cover filters as 100% as there is one GSoC project is focused on filter implementation.

from coverage report:

SuppressionsLoader.java// suppress.setModuleId(modId);

just run loader on config that have module with "id", example - https://github.com/checkstyle/checkstyle/blob/master/config/checkstyle_checks.xml#L57

SuppressionCommentFilter.java// ..... all cases

please play through accept(AuditEvent event) method to cover them.

SuppressWithNearbyCommentFilter.java// ..... all cases

please play through accept(AuditEvent event) method to cover them.

=============================

For all API code it is OK to use pure Unit Tests and ok to use reflection to check inner state of objects.
Reason: most of coverage is done by our functional test for sure, but we can not run pitest on whole project, so pure(probably ugly by reflection usage) tests is OK.

@romani

This comment has been minimized.

Show comment
Hide comment
@romani

romani Jul 19, 2017

Member

the whole code is covered in this profile.

Member

romani commented Jul 19, 2017

the whole code is covered in this profile.

@romani romani closed this Jul 19, 2017

@romani romani added this to the 8.1 milestone Jul 19, 2017

@romani romani moved this from In Progress to Done in Practice What You Preach Jul 19, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment