Listing tests from the CLI (--list-tests)

[staffanf]

I would like to have a CLI option similar to the "--tests=*SomethingTest" that only lists the tests available for a Test task without actually running them.

Expected Behavior

./gradlew test --list-tests="com.stuff.*" should list all tests that would have been run by the test task under the com.stuff package.
./gradlew test --list-tests="*StuffTest" should list all tests that would have been run by the test task in StuffTest named classes in any package.
./gradlew integTest --list-tests should list all tests that would have been run by the integTest task.

This should be similar to the --tests switch only with the added change of not actually running any tests.

Current Behavior

There is no way to only list tests in gradle today that I know of.

Context

We typically have long-running integrationTest tasks. I typically run a subset of these tests on my local machine and do not always know the exact name of the test I want to run. Currently I have to go into the source code to find the right tests. This could be replaced with a couple of quick CLI commands and perhaps grep.

[eriwen]

It'd also be awesome to have this for gradle-completion

[MartinHaeusler]

I think this feature would be very useful. I just stumbled upon this issue via google, as this was just the thing I was looking for.

My use case is to test whether my include and exclude statements work as intended.

[ror6ax]

This would be one awesome feature.

[HuangLED]

+1 this feature would be nice

[thigg]

+1

[FLXT-Qi]

+1

[ghost]

+1 for the same reason as @MartinHaeusler

[rkrisztian]

You could just use an IDE to find the classes you need.

[quidryan]

Another use-case: once tests are exposed via the CLI (or an API), external tools can partition the tests and run them on separate nodes. Each partition could be fed back into Gradle using --tests.

[msilb]

Is there any update on this feature request? As previously mentioned by @quidryan this feature would be super useful for slicing test workload across build machines in a CI/CD environment.

[XenonLX]

Stumbled upon the same issue, we need to discover a set of tests required for further execution in distributed mode, when each thread is represented by the separate host, for this, we need these names to be compatible with filtering pattern for execute via "--tests=org.smth.SomeTestName", we also expect it to work with BDD tests.

[slonka]

We need the same feature for test splitting. Right now the only solution is compiling the project, assuming tests are named ./**/*Test.* and some bash hacking. (if interested see: https://github.com/allegro/envoy-control/blob/run-tests-in-parallel-3/.circleci/config.yml#L55 https://github.com/allegro/envoy-control/blob/run-tests-in-parallel-3/run-tests-in-files.sh)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[staffanf]

At the moment, I'm not using Gradle very, although I which I was.
I still would like this 6th most voted issue to stay open so when I come back, I might reap the benefits.

[kennknowles]

👍

[siilike]

task tests {
	doLast {
		def testExecutionSpec = tasks.getByName("test") as Test

		def processor = new org.gradle.api.internal.tasks.testing.TestClassProcessor() {
			void startProcessing(org.gradle.api.internal.tasks.testing.TestResultProcessor processor) {}
			void stop() {}
			void stopNow() {}

			void processTestClass(org.gradle.api.internal.tasks.testing.TestClassRunInfo info) {
				println(info.getTestClassName())
			}
		}

		def detector = new org.gradle.api.internal.tasks.testing.detection.DefaultTestClassScanner(testExecutionSpec.getCandidateClassFiles(), testExecutionSpec.getTestFramework().getDetector()?.tap {
			setTestClasses(testExecutionSpec.getTestClassesDirs().getFiles())
			setTestClasspath(Collections.unmodifiableSet(testExecutionSpec.getClasspath().getFiles()))
		}, processor)

		detector.run()
	}
}

[rkrisztian]

@siilike, sadly internal API is prone to changes, that solution might not survive for long.

[sschuberth]

Something like this could be achieved by combining --tests with --dry-run (and eventually grep'ing the output).

[MartinHaeusler]

Any news on this matter? The JUnit test filters in gradle are really finicky in my experience, I'm having a hard time configuring them. Our integration test suite takes roughly 30 minutes for a full run and involves thousands of test cases, a trial-and-error approach in configuring the filters just isn't realistic with a cycle time as long as this.

[6hundreds]

Will be shipped in 8.3

[sschuberth]

Here's the docs: https://docs.gradle.org/8.3-rc-1/release-notes.html#dry-run-mode-for-test-execution 🙌🏻