I want to have different test tasks for UI and non-UI tasks. My UI tests extend the geb.spock.GebSpec class, so I’d like to exclude those from the regular test task and add them to the UI test task instead. My first thought was that I could override the respective test class detectors, but AFAICT that would require some serious hacking. I know I could use different packages or source sets, but I’d like to know if it’s possible to do it based on the class hierarchy anyway.
You can either use different source sets, or a package/class naming convention, or Spock’s include/exclude feature that supports filtering based on annotations and/or base classes.
I thougt of doing something like
test{
exclude{ details ->
// create classloader with test classpath, load class, check hierarchy
}
}
but the classloader is not able to load the class. I’ll keep trying, maybe I’ll figure it out eventually.
If you need inclusion/exclusion based on base class, I’d rather use the existing Spock feature. Or submit a Gradle pull request. 
I think I should describe what I’m trying to do: I’d like to end up with a gradle plugin that adds geb-spock as a dependency and adds test tasks for different browsers. Those tasks should only run the UI tests (the ones that extend ‘GebSpec’) whereas the regular ‘test’ task should only run the others. The problem with the ‘SpockConfig’ approach is that I’d have to include a different one for the ‘test’ and the ‘uitest’ task. That should be possible, but if the project already contains a ‘SpockConfig’, I’d probably end up overwriting it. Well, looks like I’m going to have to take a dive into the gradle code. 
The problem with the SpockConfig approach is that I’d have to include a different one for the test and the uitest task. That should be possible, but if the project already contains a SpockConfig, I’d probably end up overwriting it.
You just need to set ‘someTestTask.systemProperty “spock.configuration”, “file/system/or/class/path/location”’.
Yes, but that would still conflict with any spock config setting made for the project. However, I think I’ll do it that way until there is an official geb plugin for gradle (hint hint ) Thanks a lot for your help, I’ll see if I can get this to work and publish it on github.
I don’t recall if merging of Spock config files is already implemented, but it will be soon enough. A Gradle Geb plugin would be unlikely to solve this issue. It’s something that has to be implemented in Gradle’s ‘Test’ task.
Works fine so far. Gradle runs the ui tests first and the non-UI tests afterward. But the second run overwrites the test results from the first run with “empty” (i.e. ‘testsuite tests=“0” errors=“0” failures=“0”’) files for the excluded tests. If i’m going to follow the ‘SpockConfig’ approach, I’ll probably have to merge the results from the different test runs. I guess that if the ‘Test’ task were modified to allow filtering tests by annotation or base class, a potential geb plugin could make use of that functionality.
Works fine so far. Gradle runs the ui tests first and the non-UI tests afterward. But the second run overwrites the test results from the first run with "empty
You might want to configure different values for ‘testResultsDir’, and then merge them (by removing the “empty” files). This is something that a Gradle Spock plugin could improve upon. An enhanced ‘Test’ task wouldn’t have this problem in the first place.
I guess that if the Test task were modified to allow filtering tests by annotation or base class, a potential geb plugin could make use of that functionality.
Sure, but then it would only be a single line of configuration anyway. Not saying that there isn’t room for a Geb plugin.
You might want to configure different values for testResultsDir, and then merge them (by removing the “empty” files).
Beside the test results, I’d also have to merge the test reports including the overview files like ‘index.html’. This could become quite an issue.
Sure, but then it would only be a single line of configuration anyway.
I don’t think so. At least, the plugin could add the required dependencies, add different tasks for different browsers, start and stop an embedded web server (propably jetty for starters) as required, configure the test runs etc…
Maybe, extending gradle’s ‘Test’ task would be the best place to start. I’ll see what I can do.
I just pushed the code to github: https://github.com/jochenberger/gradle-geb