Please make Spock 1.x compatible with Groovy 3.x

[vanta]

Is your feature request related to a problem?

Kind of, with the upgrade to JDK 17 and so to Groovy 3.0, we'd like to avoid bumping Spock to 2.0 at this moment and put it for later (when tags support will be introduced).

Describe the solution you'd like

Making Spock 1.x compatible with Groovy 3.x would fix the problem.

Describe alternatives you've considered

No response

Additional context

No response

[kriegaex]

I cannot speak for the maintainers, but want to share my thoughts with you even so: Spock does not have a history of ever backporting any new features or even bugfixes to older versions. Spock has a basically linear version history and no maintenance branches, AFAIK. Now what you are asking is not just a small feature or bugfix but a rather major-release-defining set of things. The requirement is also pretty generic, "make compatible with Groovy 3.x" can be anything in between 2 hours (probably not) to 2 months (wild guess, but think "t-shirt size XL") of effort, depending on what you mean.

If I were you, I would not hope too much for this to ever be implemented. A very small team catering to thousands of users would have to put lots of effort into this issue for a single user who wants to avoid upgrading - not because he expects upgrading to be difficult, but because he wants to wait for yet another feature which does not exist yet.

Maybe it would help you more to investigate and discuss how to achieve what you are now doing (or planning to do) with tags with on-board Spock means instead. That might yield more progress. But that is not a good topic for an issue, rather for Stack Overflow, GitHub discussions or Gitter.

[kriegaex]

Just for reference, this issue is loosely related to previous questions about JUnit 5 tags:

• Filtering by tags in JUnit 5 prevents Spock specs from being executed #1288
• Spock 2.0-M1 - @Tag annotation from JUnit5 requires @Test annotation to work?? #1069

[vanta]

If I were you, I would not hope too much for this to ever be implemented. A very small team catering to thousands of users would have to put lots of effort into this issue for a single user who wants to avoid upgrading - not because he expects upgrading to be difficult, but because he wants to wait for yet another feature which does not exist yet.

Well, I didn't say I want to avoid migration - the problem is that tag support (tags are JUnit platform feature) is not supported in Spock 2.0 and we cannot upgrade as we heavily rely on running a dynamic set of tests (so we cannot hardcode tags in the SpockConfig.groovy file).

I'm aware of these two issues you provided, as you can see I'm not the only one having a problem with it. So if you can tell me how to dynamically filter Spock 2.0 specs by tags I'd be grateful. But AFAIR there's no way to do it, and this is why I raised this ticket.

[kriegaex]

Maybe it would help to move your issue forward, if you could provide an MCVE project, showing how you are currently using JUnit platform tags on Spock 1.3, as you said that you are heavily relying on it. That would help others to suggest an alternative for Spock 2.x and maybe motivate someone to cover your use case by adding tags support to Spock. I myself have never used those tags, but I would be interested to see their potential.

On a side note: SpockConfig.groovy is a Groovy file, as the file name implies. I.e., you can do dynamic things there to your heart's content. Whatever you can express in Groovy code, should be possible, including but not being limited to evaluating environment variables and system properties, reading and parsing configuration or POM files.

[renatoathaydes]

We had the same issue more or less... were using JUnit4 @Category to filter tests and Spock stopped supporting that in 2.+.

We ended up implementing it our own way of filtering tests based on our own annotations because we just couldn't hold off the upgrade (several thousand Spock tests and we needed to move to Java 17)... it's not too hard to implement that, though I absolutely agree it would be best to have a replacement feature in Spock itself.

[leonard84]

so we cannot hardcode tags in the SpockConfig.groovy file

That file is groovy code, so I'd argue that you can be way more dynamic that what you can achieve with some plain strings. Are you mixing Jupiter and Spock and are therefore stuck with the tag compatibility problem?

As for this request @kriegaex already said it, we don't have the resources to maintain multiple branches.

[renatoathaydes]

@vanta Here's a quick suggestion to get your tests filtered not by Spock, by the test runner.. based on what we did at work.

1. create an annotation processor whose job is just to write the name of the type annotated with an annotation.
2. before calling spock, read the file to find out which test belongs to which category (given by the annotation).
3. invoke spock with --tests so it will only run those tests.

It may sound hard but it's pretty straightforward to do.

I think you could even write a spock extension that only runs tests that have some annotation as well, depending on CLI or env vars. Assuming Spock extension lets you "skip" tests (which I believe is supported?)...

[leonard84]

Have a look at https://spockframework.org/spock/docs/2.1/all_in_one.html#_include_and_exclude you can already filter based on the presence of an annotation, what is not working is filtering on an annotation value. And let me repeat, the Spock config scripts are groovy scripts, so you can add logic there to react to env vars or system properties.

runner {
    System.getProperty("includeAnnotations")?.split(',')
        ?.collect {
            Class.forName(it) // Spock needs Class instances to filter so we need to load them with Class.forName
        }
        ?.tap { include(*it) }
}

Assuming Spock extension lets you "skip" tests (which I believe is supported?)...

Yes you can set org.spockframework.runtime.model.SpecElementInfo#setExcluded which is stronger than skip, as it will totally hide it from the engine.