How to filter executed tests using command line in a multi project build?

Hi Gradle fans,

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'.

I have open a feature request for this but never got any answer: https://github.com/gradle/gradle/issues/7748

Update: it does work with the test task is defined in allprojects block but not in subprojects block.

3 Likes

Nobody has never ever wanted to do that?

That should work.

Can you run ./gradlew help --task test to verify the test task is of type Test?

Using freshly release Gradle 5.0:

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.