We can run junit batchtest with tests picked from a jar file. This runs all matching tests picked from test-only.jar
How to do similar thing with gradle. The testClassesDir only takes actual directory.
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…
Thank you for describing your use case! I’ve exported this ticket to jira so that users can vote.
the stackoverflow post mentioned in this thread talks about extracting the jar to run tests. Is there any example of it?
Hi,
I’m about to setup a test using JAR files exported form Artifactory. I would like to know before hand if this issue has been fixed. What is the JIRA ticket which was created?
Thanks, Damien.
So, is it now the case that we can run tests from a jar file using gradle?
I’m not understanding why you would want to do this. Lets say that the project-test.jar is already on your classpath and so your test runner (either Maven Surefire or Gradle) will pick up the classes (by the defined filter) from that .jar without having to unzip anything.
So, isn’t this question really just re-inventing the wheel and/or redundant?
Hi,
The current test task in Gradle does not allow you to filter on classes that are part of a JAR file. We’ve tried and failed.
Our current (ugly) workaround is to use ANT JUnit.
Regards, Damien.
Yes. I followed the ant approach as mentioned in http://stackoverflow.com/questions/21439082/gradle-to-run-tests-from-test-dependency-jars
Hard to believe but I can see that one of the gradle team members agrees on that point.
It sounds like it is because “testClassesDir” cannot be defined currently as a .jar file location.
Interesting. I think Maven Surefire has the same issue and people get around it by using the ‘maven-dependency-plugin’ with a ‘unpack’ goal. So, that sounds like a similar thing.
FYI, there is a pending pull request about this very issue: https://github.com/gradle/gradle/pull/194
Running tests from a jar file is critical. Junit is now used for alot more than just developer tests. its become a standard for Java based integration tests (bigtop’s itest library, for example, uses it to test clusters of 100s of hadoop machines).
And compiles jars specifically for this purposes which are known to be compiled against particular hadoop libraries).
So its very critical to support running unit tests from a compiled jar.
hope to get the feature in soon !
The use case we have is trying to run Acceptance tests in a delivery pipeline.
By keeping the tests along side the source code to make sure the versions are consistent, we need to generate a jar of our acceptance tests that we would like to run in the next stage of the pipeline (using Jenkins Build Pipeline if your interested).
In moving towards a Continuous Delivery set up this would be a big help.
Also with Microservice Consumer Driven Contact tests, you may also want to generate a jar during the initial stage of the pipeline.
+1 for this feature.
My use-case is running a TCK against my implementation (jsr107). The TCK guide recommends importing the project, updating the pom file, and running it in IntelliJ. That is a pretty disappointing (and disgusting) approach towards standards verification. I’d prefer integrating it through Gradle instead, as the TCK consists of a suite of JUnit tests and is published to Maven Central.
This has come up a few times and is a popular feature request. Unfortunately, it requires some rejigging of internals which is where previous contributor initiatives to get it done have lost steam.
If you’re interested in helping get this done, it would be great to start a conversation on the dev list about it.
Its no longer pressing so, to be honest, I won’t be motivated enough to drive it to completion. I was able to work around this by unzipping the archive and setting the testClassesDir. That’s actually a perfectly good solution in my opinion (due to the awesome flexibility of Gradle), except that I can’t figure out how to attach the test sources for Eclipse…