The 'Run as >> JUnit test' indeed doesn't use gradle to run tests. It uses the Eclipse built-in JUnit test runner.
Eclipse never executes Gradle code the only way to execut gradle code is by running tasks (or implicitly when building a Gradle model for the tools).
You are really opening a 'can of worms' here. I certainly understand that you'd want this to work somehow I'm just not sure how to make that happen.
But I can see (at least) two possible ways to try to move forward:
1) try to make some kind of test integration for gradle by running tests with gradle tasks from within STS (like 'Run As >> JUnit test' but then called 'Run As >> Gradle Test'. The tricky part here is to make the test results display nicely in the IDE, make the tests debugable with the Eclipse debugger, make individual tests selectable and 're-runable' etc. None of these things will work automatically and may require a lot of work. The Eclipse Junit testing infrastructure isn't really built to be extensible unfortunately. And I don't know how much gradle facilitates running individual tests.
2) try to integrate gradle tasks somehow into the Eclipse build. So that when Eclipse does a build some tasks can be made part of the build somehow. There's already an issue open for something like that:
With number 2, maybe your project could be setup so that a task that you want executed to do some preprocessing / copying could be called upon automatically. Depending on how you set it up, this may make the Eclipse test infrastructure then work with some parts of the build being done in Eclipse and some 'special stuff' to be done by a gradle task you told it to run.
I'm not sure how practical #2 would be and if it would work in this case.
We can certainly explore the options further.
Can you 'fix' the problems by running a specific gradle task manually before running the tests?
If the answer is yes, then there's some hope that #2 could help you automate this and help you with your problem.
Kris De Volder -- SpringSource