No mutable classes found when tests in separate module
srmo opened this issue · 8 comments
Hi, when having tests and prod-code in different modules, org.pitest:pitest-maven:mutationCoverage will result in
[ERROR] Failed to execute goal org.pitest:pitest-maven:1.1.6:mutationCoverage (default-cli) on project my-app-test: Execution default-cli of goal org.pitest:pitest-maven:1.1.6:mutationCoverage failed: No mutations found. This probably means there is an issue with either the supplied classpath or filters.
verbose shows that pitest will look in target/classes, which is empty in the test module.
How can I solve this? (Maybe the solution is some maven magic I'm not aware of?)
The base configuration limits the code being mutated to the classes under target/classes. That's usually fine because that's the easiest way to distinguish production code that SHOULD be mutated and libraries that SHOULD NOT be mutated.
Maybe you could use maven-dependency-plugin to get your production classes copied into target/prod-classes folder and then use the additionalClasspathElements to add your production classes to pitests classpath for tests and mutated code.
Another option would be to use the maven ant task via maven. But this requires much more setup, I think.
Subscribing, because our multi-module project has multiple modules that don't have code in src/main, only in src/test, because
- the code is not written yet
- modules for testing and profiling
It would help for me if there was a way to exclude certain modules that don't have production code.
I think a workaround can be found in #182 (comment)
EDIT: I can confirm that the workaround works for me.
Don't know whether this is exactly the case @srmo has.
If it's okay for you to skip/exclude tests from modules that don't have production code you've got two options:
a) Use the approach you described as workaround (although I'd like to name it a solution, not a workaround ;-) ): Configure pitest in the <plugin> section of your maven parent pom.xml and deactivate it explicitly using the <skip> parameters for those modules that do not have production code.
b) Configure pitest in the <pluginManagement> section of your maven parent pom.xml and add <execution>s for those modules that should be mutation-tested or alternatively declare them in a profile in each and every module that should be mutation-tested.
I'd prefer solution a) and I'm successfully using this for multiple projects. I'd rather use opt-out (solution a)) than opt-in (solution b)) becaues I might miss new modules otherwise and because the configuration is shorter ;-).
@srmo
Did you find a solution or work around? Does you problem still exist? Was my comment helpful?
I think a solution could be implementing the --sourceDirs in the maven plugin too. As far as my understanding goes, the "workaround" for this problem used in Pitclipse (if you set it up to have "Pit execution scope" = "All project in the workspace") it that it supplies the directories from other projects as value for the mentioned CLI argument.
Edit: sorry, I was a bit misunderstanding the thread. What I was thinking about: this would be a solution to the problem where your test classes are in a separate project than the code tested.
Btw, something like that is supported in the Gradle plugin for PIT - see this example.
Re: @KyleRogers Sep 5, 2015
Copying the class files (I did it with the maven resources plugin) indeed circumvents the problem, and is parameterizable (i.e., from/to where to copy, etc.).
Sidenote: if you are using the resources plugin, turn filtering off :)
Note2: It's not entirely a good solution though, the additionalClasspathElements seems not to work as desired (i.e., even though the correct folder is added to the path, no classes are found). This leaves that you have to copy the source classes into target\classes.
Note3: Additonally, the source is missing in this case, so the report is not-so-usable. This leads back to my first comment about the --sourceDirs.