Make Spock compatible with @CompileStatic?

[Thibault Kruse]

Hi,

currently when applying @CompileStatic to a Spock Specification with a "where:" block, I get the following exception:

@CompileStatic

class SimpleSpec extends Specification {

    def testMax(int a, int b, int c) {

        expect:

        Math.max(a, b) == c

        where:

        a    | b   | c

        5 | 1 | 5

        3 | 9 | 9

    }

}

Error:(11, 9) Groovyc: Target method for method call expression hasn't been set

I wonder whether the transform could be extended to allow @CompileStatic. Has this been tried yet?

[rfle...@netflix.com]

No, the specification itself won't work with @CompileStatic (or @TypeChecked). What you can do is define helper methods in statically compiled traits and implement those traits in the specification class.

[Thibault Kruse]

I know it currently does not work. The question is whether Spock can be changed to make it work in Spock 1.1.0 or so.

[Luke Daley]

Most syntax can theoretically be made to work. Some of the mocking syntax exploits dynamism though and won’t. 

On the priority list for Spock @CompileStatic support doesn’t rate highly for me, especially considering that 100% support won’t be possible without reworking certain API.

--
You received this message because you are subscribed to the Google Groups "Spock Framework - User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spockframewor...@googlegroups.com.
To post to this group, send email to spockfr...@googlegroups.com.
Visit this group at http://groups.google.com/group/spockframework.
For more options, visit https://groups.google.com/d/optout.

[Gilad Bar Orion]

Hi,

I'm a novice Spock/Groovy user, POC-ing migrating my team's JUnit test suite to Spock (production code is in Java).

It's very convenient (and expected, for people coming from a Java background) to get instant IDE error indications when e.g. you refactor your production class and the Spock tests are no longer synced (e.g. method renaming) 

Unless I've missed something, the only way to get such behavior (at least in Eclipse) is by using @CompileStatic - which doesn't work with Spock.

So at least as a selling feature for people coming from Java and used to some static safety, supporting @CompileStatic does have a value...

Thanks

Gilad

[Peter Niederwieser]

If what you are after is type checking, @TypeChecked should work fine (although I haven’t tried). No need for static compilation here.

Refactoring your Java code should automatically change the Groovy code as well (otherwise you’ve found a bug in the Groovy Eclipse plugin).

-Peter

[Kostis Kapelonis]

As Peter said make sure that your project has the Groovy nature
enabled to gain automatic refactoring from Java to Groovy.

The particular scenario you mention (method renaming by external
means) works out of the box (without using @TypeChecked or anything
else).
It is just that Eclipse underlines the unknown method (instead of
creating an error as you might expect)

See attached screenshot.

[Gilad Bar Orion]

Thanks Peter, Kostis!

My method renaming example was a little too simplistic, and is indeed covered by an eclipse refactoring.

But it's easy to bump into a real world refactoring that isn't (a recent one for me was refactoring two methods: recordOperationStartTime() and recordOperationEndTime() to a single method: recordOperationDuration(long duration)) 

getting those 'inferencing_problems' indicated as underlined text in Eclipse is far from ideal, as you have to proactively remember to look for it in the suitable unit test file(s). Of course you should run your unit test after each change, but still it's a an order of magnitude less tighten to your changes.

Adding @TypeChecked I was able to get eclipse to mark the errors in the file in red as expected, but it does not appear to drive eclipse to display any of those errors in the problems view (or in the markers view). So it's hardly ideal also.

While this may be solved at some point by a groovy eclipse plugin improvement, I wasn't able to find the syntax for defining mocks to work with @TypeChecked. For example, who can I the following to pass type checking:

@TypeChecked

class MyDecoderSpec extends Specification {

TcpProtocol protocol = (TcpProtocol) Mock(TcpProtocol) { getHeaderVersion() >> 2 }

I'm getting errors like:

Groovy:[Static type checking] - Cannot find matching method com...connections.tcp.netty.MyDecoderSpec#getHeaderVersion(). Please check if the declared type is right and if the 

 method exists.

Why is it looking for getHeaderVersion() in the Spec? I've also tried relocating the mock definition to other blocks but failed to make it work.

Thanks

Gilad

[Peter Niederwieser]

I never have problems with Java/Groovy cross-language refactoring in IntelliJ. Groovy Eclipse isn’t quite as good (in particular I found it to be less stable/reliable), partly because Eclipse simply doesn’t provide the same cross-language IDE infrastructure. That said, in the worst case you’ll find the problem the very next time you’ll run your specs. 

Please file a Spock issue for the concrete problem you mentioned. Meanwhile, you may get better IDE support by not using the most complex mocking syntax and instead separating mock instantiation and declaration of interactions.

Cheers,

Peter