hcoles
Maven package detection misses tests in different packages
The maven plugin no longer assumes that classes will be in packages that match the group id, and instead scans the target/classes to build a list of packaged.
The target tests is also be set to this list, excluding any tests that do not live in a package that exists in the production code tree.
This is often fine, but will miss tests for some projects.
If I am understanding this correctly, this maven-plugin considers only those tests that fall under "projectId.groupId." But a test may be there in some other package like "projectId.xyz.groupId." and that test is ignored. Am I right?
When I ran 'mutationCoverage' goal, I was expecting targetTests to be set to the same package as targetClasses at https://github.com/hcoles/pitest/blob/master/pitest-maven/src/main/java/org/pitest/maven/MojoToReportOptionsConverter.java#L103 but the list of targetTests was empty, can you please explain why? My test is in the same package as my class in src/test/java folder under package "projectId.groupId.*
This hit me hard yesterday. I like to put my tests in completely different packages than my production code, so I can't accidentally access package private code; I only want to test public apis. As I hadn't run pitest for a while, it took me half a day to find the cause... and I don't like the fix. Now I've built a demo project for this here.
@hcoles: do you think this would be a difficult issue to fix? If it's suitable for someone new to the pitest code base, could you give me a hint on how to start?
@t1 Thanks for the example project.
The issue here is that pitest is only scanning the maven output directory to discover packages. If a package exists only in the test-output directory it doesn't see it. When no explicit filter is applied the same glob is used for both tests and production code.
It should be pretty straightforward to fix if you'd like to take a shot.
The correct fix would be to separately scan the test output directory for test packages.
A marginally easier fix would be to scan both and use the same combined list for the target classes and target tests filters.
Scanning occurs in MojoToReportOptionsConverter.determineTargetClasses.
I think the only meaningful way to test this would be to add another integration test to the pitest-maven-verification module.
It's been almost a year now, but as much as I'd like to help, I'm way to busy with other stuff. I just wanted to let you know.