I would like to filter tests executed in a multi project build in order to separated unit tests from integration tests. I know I can create another ‘test’ task to achieve this but I don’t want to because it brings additional complexity.
I want to be less intrusive and do the filtering using the command line.
This is unfortunately not working as you can see below (using Gradle 4.10 or snapshot of 5.X)
ghilaima@ghilaima-linux:~/projects/gradle-project(develop)$ ./gradlew test --tests someTest
FAILURE: Build failed with an exception.
* What went wrong:
Problem configuring task :test from command line.
> Unknown command-line option '--tests'.
ghilaima@ghilaima-linux:~/projects/prototype-build(develop)$ ./gradlew help --task test
Configuration on demand is an incubating feature.
Ignoring listeners of task graph ready event, as this build (:fwk-plugins-gradle) has already executed work.
Ignoring listeners of task graph ready event, as this build (:fwk-plugins-gradle) has already executed work.
> Task :help
Detailed task information for test
Path
:test
Type
Task (org.gradle.api.Task)
Description
-
Group
-
Deprecated Gradle features were used in this build, making it incompatible with Gradle 6.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/5.0/userguide/command_line_interface.html#sec:command_line_warnings
BUILD SUCCESSFUL in 4s
1 actionable task: 1 executed
ghilaima@ghilaima-linux:~/projects/prototype-build(develop)$ ./gradlew test --tests *IT
Configuration on demand is an incubating feature.
Ignoring listeners of task graph ready event, as this build (:fwk-plugins-gradle) has already executed work.
Ignoring listeners of task graph ready event, as this build (:fwk-plugins-gradle) has already executed work.
FAILURE: Build failed with an exception.
* What went wrong:
Problem configuring task :test from command line.
> Unknown command-line option '--tests'.
* Try:
Run gradlew help --task :test to get task usage details. Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
Deprecated Gradle features were used in this build, making it incompatible with Gradle 6.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/5.0/userguide/command_line_interface.html#sec:command_line_warnings
BUILD FAILED in 2s
´´´
does your root project has the java plugin applied? There is a problem here with using task name matching across a multiproject build. I usually run a specific test task of a subproject in combination with the --tests flag.
No, it does not. Why should I apply it to the root project? I just want to apply to subprojects. Some project may also have no tests at all (or not be java projects).
I also want to know if there is a way to make it work with composite build, which is even more complex. Is there documentation somewhere explaining how options are supported for multi project build and composite builds? It is quite unclear for me.
You should not apply the java project in the root. The question was just for me to get the whole picture. In general when using task commandline options you should trigger a specific task (e.g via ./gradlew :subproj:test --tests .... Unfortunately, the ability to target a task or tasks in an included build directly from the command line is not supported at the moment.
Why do you say in general when using command line options? Where is this ‘guideline’ mentioned? Is there any reasoning behind this?
In my case I have a CI job and I want to build my multi project build using gradle test --tests *Test to skip the integration tests. I don’t want to have to specify all the sub project independently otherwise I loose the advantage of the multi project build.