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

Skip Pitest task execution test when source set is empty #294

Open
davidburstrom opened this issue Sep 12, 2021 · 6 comments
Open

Skip Pitest task execution test when source set is empty #294

davidburstrom opened this issue Sep 12, 2021 · 6 comments
Milestone

Comments

@davidburstrom
Copy link
Contributor

For a regular Gradle test task from the Java plugin, if there is no test source, it will just be skipped indicating NO-SOURCE. In contrast, Pitest tasks will fail with Coverage generation minion exited abnormally. I propose that the Pitest tasks should behave similarly as the test task. As for backwards compatibility, this would cause e.g. CI builds that are currently failing to pass instead, but I have a hard time seeing that as a problem.

The current workaround I use is pretty hard-coded (and deals with configuration caching, hence it looks a little weird):

tasks.named<PitestTask>("pitest").configure {
  inputs.property("src", file("src/test"))
  onlyIf {
    (inputs.properties.get("src") as File).exists()
  }
}
@davidburstrom davidburstrom changed the title Skip Pitest task execution test source set is empty Skip Pitest task execution test when source set is empty Sep 12, 2021
@szpak
Copy link
Owner

szpak commented Sep 12, 2021

It sounds sensible. Currently the plugin is applied only on subprojects with the Java plugin, but no test source in fact could lead to that behavior. Nevertheless, in a corner case, there could be only some test content attached from some other subprojects (e.g. with the acceptance tests).

task.additionalClasspath.setFrom({
List<FileCollection> testRuntimeClasspath = (extension.testSourceSets.get() as Set<SourceSet>)*.runtimeClasspath
FileCollection combinedTaskClasspath = project.objects.fileCollection().from(testRuntimeClasspath)
FileCollection filteredCombinedTaskClasspath = combinedTaskClasspath.filter { File file ->
!extension.fileExtensionsToFilter.getOrElse([]).find { extension -> file.name.endsWith(".$extension") }
} + project.files(allMutableCodePaths)
return filteredCombinedTaskClasspath
} as Callable<FileCollection>)

Do you think that checking if additionalClasspath has some entries would be sufficient? Or you have some better proposal?

@szpak
Copy link
Owner

szpak commented Sep 12, 2021

Btw, it is slightly related to #292 (in terms of behavior).

@davidburstrom
Copy link
Contributor Author

The additionalClasspath has entries from the main source set (which for all practical purposes definitely should have entries) as well as test runtime classpath elements, so that won't work.

I was thinking that it should be sufficient to check if project.objects.fileCollection().from(extensions.testSourceSets.get() as Set<SourceSet>)*.allSource) is non-empty, but haven't verified that theory.

@szpak
Copy link
Owner

szpak commented Sep 12, 2021

Yes, testRuntimeClasspath extends the main classpath.

Maybe, but source sets were always somehow specific for me and it would have to be verified :-).

@davidburstrom
Copy link
Contributor Author

It is of course true that the test classpath can contain the test cases, imported from another project. I'm not sure if that is a sufficiently common case...

Using @SkipWhenEmpty @InputFiles on a property populated accordingly should result in a NO-SOURCE status. Not that it's critical that the status is the same as for a Test task.

Gradle Test solves it by having a testClassesDirs property which is separate from the test runtime classpath.

@szpak szpak modified the milestones: 1.7.0, 1.7.1 Sep 13, 2021
@szpak szpak modified the milestones: 1.9.0, 1.9.1 Aug 19, 2022
@szpak szpak modified the milestones: 1.9.11, 1.9.12 Nov 25, 2022
@esfomeado
Copy link

Any plans of when this would be available.

So far I have to exclude certain modules from running the pitest task.

@szpak szpak modified the milestones: 1.14.0, 1.14.1 Sep 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants