SpockConfig can include/exclude by regex pattern string.

[jdbeutel]

Please consider adding this to Spock. You mentioned that it would be good to do.

The regex pattern is matched against the simple name
of the annotation, spec, or feature. This addresses
http://code.google.com/p/spock/issues/detail?id=184

Also added to new_and_noteworthy, and updated javadoc in
IncludeExcludeExtension and RunnerConfiguration. Removed an apparently
obsolete part of the example from the latter, because it didn't work
when I tried it, and there are no specs for it.

I would have liked to use GrailsTestTargetPattern with its AntPathMatcher,
but that seemed out of scope for Spock.

[tom-mi]

+1

[leonard84]

I've discussed it with @robfletcher and we would like the following changes before it can be accepted:

• rebase on master branch
• enhance the criteria to support Class/String/Pattern, e.g.

runner {
  include Fast, 'my.package.IntegrationTest', ~/.*Spec/
} 

• String should behave like the class criteria, i.e., matching both annotations and baseClass names using FQCN

[jdbeutel]

I'll look at this over the weekend. I originally used FQCN, but with regex, the package dots should be escaped, e.g., 'my.package.IntegrationTest', or '*.IntegrationTest', and I didn't like how that looked. Then Grails included Spock, so I couldn't use my own version with this enhancement anymore, so I did what I needed a different way (using my own global extension), and haven't been using this. So, my "new and noteworthy" comment that this is useful in Grails isn't true anymore, unless/until Grails updates its bundled Spock to include this.

[robfletcher]

I'm curious, does Grails 3 even use the Spock plugin any more? I haven't done anything with Grails 3 other than taking a brief look. It seems the plugin may be somewhat redundant since the framework is now integrated with Gradle. I may be missing something, though.

[jdbeutel]

I haven't really looked at Grails 3 yet; I'm still on 2.4.5, which I don't think uses the plugin, just spock-core:0.7-groovy-2.0 directly.

[jdbeutel]

Besides matching Pattern/String on FQCN, should it behave like the Class criteria with respect to inheritance? The baseClass matching uses isAssignableFrom(), but pattern matching like that would need to iterate up the superclasses/interfaces(/traits?).

[leonard84]

Hm, you could use Class.forName() with the appropriate try/catch and then use the existing matching method. We should have access to the class at that point.

[jdbeutel]

Are you suggesting that it try to get a Class based on the Pattern/String, i.e., if it is literally the FQCN, in addition to regex matching? I wonder if Spock's Classloader will really have access to the class at that point, when it wasn't available for a Class literal in the config stage. I guess it wouldn't hurt to try, though.

[leonard84]

As I said before we have three types of matchers:

1. Class Object: Fast
2. String which is FQCN of the classes only, no regex matching: 'my.package.IntegrationTest'
3. Pattern Instance which is only matched against the Feature names. Pattern literal syntax in groovy is ~/regex/, e.g., ~/.*Spec/

The classloader should have access to the class in the IncludeExcludeExtension how else could you check it? You can also use Class.forName(fqcn, false, classloader ) to use another classloader, but I doubt it would be necessary..

[jdbeutel]

I don't see the original issue on Grails 3.0.2 or 3.0.3. They use spock-core:1.0-groovy-2.4, but apparently load SpockConfig.groovy with a classpath that includes classes under src/test and src/main. So, is there still any use case for SpockConfig with String instead of Class Object? Or, should this PR add only Pattern?