[GRADLE-412] Change semantics for 'test' task. Created: 19/Feb/09  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Improvement
Reporter: Jon Cox Assignee: Unassigned
Resolution: Won't Fix Votes: 0



  • Gradle now has support for Junit and TestNG
  • Gradle will someday support builds for code written in C/C++
  • Some 'test' targets may end up being used for non-JVM languages (e.g.: C/C++)
  • Gradle may provide richer support for fancy production runtime configs (not just test runtime configs)

It seems like the original meaning of the 'test' target needs to be abandoned in favor of more specific targets;
the useJunit() and useTestNG() functions within 'test' feel like a kludge to work around the current ambiguity.

Hence, we could have specfiic top-level target like this:

Run junit task (which runs junit tests)
% gradle junit

Run testng task (which runs testng tests)
% gradle testng

If someone wants a 'test' target, they can make one easily enough:

createTask("test", dependsOn: "junit")

If someone wanted to run a java program in a non-test mode
and do something like: "java -cp $runtime.asPath() blabla".execute(),
we could have a 'java' task:

% gradle java

If someone wanted to run a java-based task more abstractly, they could
do something like this:

createTask("run", dependsOn: "java")

That way, gradle could be used to "run" c++ code and java code...
or whatever else you'd like in a non-test config too (and do so
on a project-by-project basis).

It would be interesting to see what thoughts folks have on the
mailing list; hopefully we can use JIRA to track the issue once
some consensus is reached & lurking issues are flushed out
(such as what this means for the build dir structure and the
default include/exclude patterns).

Comment by Tom Eyckmans [ 27/Feb/09 ]

I think the current reason why we need the useJUnit and useTestNG methods is because we don't have an intelligent way of deciding which test framework is used. We could do this based on for example what test framework is in testCompile.

I also think that we currently make it rather hard to have more than one test task, I would like to see something in the general direction our dependency DSL is going, use the test { } more like a factory for test tasks (same goes for compile tasks)

test {

{ dependsOn batchTestCompile // assuming multiple compile tasks here (but this doesn't imply that there are multiple testCompile dependency configurations) - determine test framework based on compiled classes }


{ dependsOn devTestCompile }

report batchTest

To make this work independent of the language of the code, we need to pull out the test framework specific implementation code into separate plugins and allow plugins to depend on others (the junit and testng plugins should depend on the java plugin), we also need a typing system for our plugins to allow the java plugin to find depending plugins of type TestFramework so the JavaPlugin can ask the available matching plugins if they can run the test code.

This way we can allow users to create more test tasks by names they want and have all this work smart and independend of the language of the code.

I even think we could make this work if you have both C++ and java sources in the same module, we just need to be smarter, like with detecting the test framework we need to have a Compiler plugin type that knows what it can compile and the compile { } task factory has to smart use that knownledge to determine what Compiler plugin to use.

about the run stuff we could do something very similar
execute {

{ // because you depend on myArtifact we know you want to execute java -jar if myArtifact is of type jar with all dependencies on the classpath dependsOn myArtifact args 'blabla' }


I think we can be smart about most of this and when we can figure it out additional functions / parameters will provide an easy way of making the build do what is wanted.

Comment by Benjamin Muschko [ 15/Nov/16 ]

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!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 11:29:26 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.