Sorry, this feature is not supported ATM. I'm curious, why do you keep test classes in the jar?

I have a very large code base. Once built, I could move the build onto another machine with more computing power and run tests in parallel. Test and application code all are in jar files.

Current work around is to expand all test-jars in to a directory and use that directory to get tests from. This is redundant and tests are already in jars..

It's also useful when the tests are truly integration or system tests. I'm going to implement the work around of extracting and running the jars. Another alternative is to just run them from Ant, which supports this.

Another vote for this feature. It could be really useful for our build pipeline, where we compile our integration tests together with everything else, and run them in a later stage of our pipeline..

I made a pull request (proposal) for this feature:

https://github.com/gradle/gradle/pull/194

This is indeed quite an important feature. In a continuous delivery pipeline, we want to be able to download binaries & deployment configurations from an artifact repository, deploy the application on a server, and run some tests. Those tests will be also packaged as JAR files, and the tests should be able to run using those JAR directly.

Of course, we can always revert back to ANT. But then, what's the point of using Gradle in the first place?

Damien.

I would like to do this as well. While waiting on Gradle to implement this feature, what are the ways around this for now? I see the "extract the jar..." option, but I also see that they can be run using Ant. My code is in Groovy... could I use the Groovy ANT functionality to do this?

Are the test classes still included in src/test/groovy|java to get them compiled in the jar file?

FYI, I've written an article about creating executable acceptance tests: https://nemerosa.ghost.io/2014/11/05/executable-acceptance-tests-using-spring-boot/ It's using Spring Boot, but I think this could be done using other technologies. This allows me to store the acceptance tests as an artifact and to run them all along my deployment pipeline.

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

+1, I still believe this is important, especially for integration tests. I'm currently converting a legacy bash+ant built application split over 20-50 subprojects where each subproject publishes integrations tests for itself and dependent modules. I haven't found a simple way to run the integration tests from the submodules in gradle.

I also would like to see this fixed.

I too, would like to see this fixed.

I created https://github.com/gradle/gradle/issues/1007 for this