Make Spock compatible with @CompileStatic?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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?

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/spockframework.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Make Spock compatible with @CompileStatic?

rfletcher
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.

On Monday, March 16, 2015 at 8:09:41 PM UTC-7, Thibault Kruse wrote:
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?

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/spockframework.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Make Spock compatible with @CompileStatic?

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.

On Tuesday, March 17, 2015 at 7:17:46 PM UTC+1, [hidden email] wrote:
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.

On Monday, March 16, 2015 at 8:09:41 PM UTC-7, Thibault Kruse wrote:
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?

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/spockframework.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Make Spock compatible with @CompileStatic?

Luke Daley-2
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.

On 18 March 2015 at 7:18:11 pm, Thibault Kruse ([hidden email]) wrote:

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.

On Tuesday, March 17, 2015 at 7:17:46 PM UTC+1, [hidden email] wrote:
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.

On Monday, March 16, 2015 at 8:09:41 PM UTC-7, Thibault Kruse wrote:
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?
--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/spockframework.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/spockframework.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Make Spock compatible with @CompileStatic?

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

On Tuesday, March 24, 2015 at 7:41:22 AM UTC+2, Luke Daley wrote:
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.

On 18 March 2015 at 7:18:11 pm, Thibault Kruse (<a href="javascript:" target="_blank" gdf-obfuscated-mailto="nnPP_B1uP1cJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">thibaul...@...) wrote:

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.

On Tuesday, March 17, 2015 at 7:17:46 PM UTC+1, [hidden email] wrote:
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.

On Monday, March 16, 2015 at 8:09:41 PM UTC-7, Thibault Kruse wrote:
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?
--
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="nnPP_B1uP1cJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">spockframewor...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="nnPP_B1uP1cJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">spockfr...@googlegroups.com.
Visit this group at <a href="http://groups.google.com/group/spockframework" target="_blank" rel="nofollow" onmousedown="this.href='http://groups.google.com/group/spockframework';return true;" onclick="this.href='http://groups.google.com/group/spockframework';return true;">http://groups.google.com/group/spockframework.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;">https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/spockframework.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Make Spock compatible with @CompileStatic?

Peter Niederwieser
Administrator
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

On 29 Jun 2015, at 10:01, Gilad Bar Orion <[hidden email]> wrote:

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

On Tuesday, March 24, 2015 at 7:41:22 AM UTC+2, Luke Daley wrote:
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.

On 18 March 2015 at 7:18:11 pm, Thibault Kruse (<a href="javascript:" target="_blank" gdf-obfuscated-mailto="nnPP_B1uP1cJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;" class="">thibaul...@...) wrote:

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.

On Tuesday, March 17, 2015 at 7:17:46 PM UTC+1, [hidden email] wrote:
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.

On Monday, March 16, 2015 at 8:09:41 PM UTC-7, Thibault Kruse wrote:
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?
--
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="nnPP_B1uP1cJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;" class="">spockframewor...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="nnPP_B1uP1cJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;" class="">spockfr...@googlegroups.com.
Visit this group at <a href="http://groups.google.com/group/spockframework" target="_blank" rel="nofollow" onmousedown="this.href='http://groups.google.com/group/spockframework';return true;" onclick="this.href='http://groups.google.com/group/spockframework';return true;" class="">http://groups.google.com/group/spockframework.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;" class="">https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/spockframework.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/spockframework.
For more options, visit https://groups.google.com/d/optout.

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Make Spock compatible with @CompileStatic?

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.


On Tue, Jun 30, 2015 at 12:51 AM, Peter Niederwieser <[hidden email]> wrote:

> 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
>
> On 29 Jun 2015, at 10:01, Gilad Bar Orion <[hidden email]> wrote:
>
> 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
>
> On Tuesday, March 24, 2015 at 7:41:22 AM UTC+2, Luke Daley wrote:
>>
>> 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.
>>
>> On 18 March 2015 at 7:18:11 pm, Thibault Kruse ([hidden email])
>> wrote:
>>
>> 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.
>>
>> On Tuesday, March 17, 2015 at 7:17:46 PM UTC+1, [hidden email] wrote:
>>>
>>> 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.
>>>
>>> On Monday, March 16, 2015 at 8:09:41 PM UTC-7, Thibault Kruse wrote:
>>>>
>>>> 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?
>>
>> --
>> 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 [hidden email].
>> To post to this group, send email to [hidden email].
>> Visit this group at http://groups.google.com/group/spockframework.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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 [hidden email].
> To post to this group, send email to [hidden email].
> Visit this group at http://groups.google.com/group/spockframework.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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 [hidden email].
> To post to this group, send email to [hidden email].
> Visit this group at http://groups.google.com/group/spockframework.
> For more options, visit https://groups.google.com/d/optout.
--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/spockframework.
For more options, visit https://groups.google.com/d/optout.

eclipse-underline.png (34K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Make Spock compatible with @CompileStatic?

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


On Tuesday, June 30, 2015 at 1:15:40 AM UTC+3, Kostis Kapelonis wrote:
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.


On Tue, Jun 30, 2015 at 12:51 AM, Peter Niederwieser <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="1he7lpmqvG0J" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">pnie...@...> wrote:

> 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
>
> On 29 Jun 2015, at 10:01, Gilad Bar Orion <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="1he7lpmqvG0J" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">bar....@...> wrote:
>
> 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
>
> On Tuesday, March 24, 2015 at 7:41:22 AM UTC+2, Luke Daley wrote:
>>
>> 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.
>>
>> On 18 March 2015 at 7:18:11 pm, Thibault Kruse ([hidden email])
>> wrote:
>>
>> 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.
>>
>> On Tuesday, March 17, 2015 at 7:17:46 PM UTC+1, [hidden email] wrote:
>>>
>>> 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.
>>>
>>> On Monday, March 16, 2015 at 8:09:41 PM UTC-7, Thibault Kruse wrote:
>>>>
>>>> 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?
>>
>> --
>> 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 [hidden email].
>> Visit this group at <a href="http://groups.google.com/group/spockframework" target="_blank" rel="nofollow" onmousedown="this.href='http://groups.google.com/group/spockframework';return true;" onclick="this.href='http://groups.google.com/group/spockframework';return true;">http://groups.google.com/group/spockframework.
>> For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;">https://groups.google.com/d/optout.
>
>
> --
> 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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="1he7lpmqvG0J" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">spockframewor...@googlegroups.com.
> To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="1he7lpmqvG0J" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">spockfr...@googlegroups.com.
> Visit this group at <a href="http://groups.google.com/group/spockframework" target="_blank" rel="nofollow" onmousedown="this.href='http://groups.google.com/group/spockframework';return true;" onclick="this.href='http://groups.google.com/group/spockframework';return true;">http://groups.google.com/group/spockframework.
> For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;">https://groups.google.com/d/optout.
>
>
> --
> 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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="1he7lpmqvG0J" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">spockframewor...@googlegroups.com.
> To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="1he7lpmqvG0J" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">spockfr...@googlegroups.com.
> Visit this group at <a href="http://groups.google.com/group/spockframework" target="_blank" rel="nofollow" onmousedown="this.href='http://groups.google.com/group/spockframework';return true;" onclick="this.href='http://groups.google.com/group/spockframework';return true;">http://groups.google.com/group/spockframework.
> For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;">https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/spockframework.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Make Spock compatible with @CompileStatic?

Peter Niederwieser
Administrator
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

On 01 Jul 2015, at 14:39, Gilad Bar Orion <[hidden email]> wrote:

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


On Tuesday, June 30, 2015 at 1:15:40 AM UTC+3, Kostis Kapelonis wrote:
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.


On Tue, Jun 30, 2015 at 12:51 AM, Peter Niederwieser <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="1he7lpmqvG0J" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;" class="">pnie...@...> wrote:

> 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
>
> On 29 Jun 2015, at 10:01, Gilad Bar Orion <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="1he7lpmqvG0J" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;" class="">bar....@...> wrote:
>
> 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
>
> On Tuesday, March 24, 2015 at 7:41:22 AM UTC+2, Luke Daley wrote:
>>
>> 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.
>>
>> On 18 March 2015 at 7:18:11 pm, Thibault Kruse ([hidden email])
>> wrote:
>>
>> 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.
>>
>> On Tuesday, March 17, 2015 at 7:17:46 PM UTC+1, [hidden email] wrote:
>>>
>>> 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.
>>>
>>> On Monday, March 16, 2015 at 8:09:41 PM UTC-7, Thibault Kruse wrote:
>>>>
>>>> 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?
>>
>> --
>> 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 [hidden email].
>> Visit this group at <a href="http://groups.google.com/group/spockframework" target="_blank" rel="nofollow" onmousedown="this.href='http://groups.google.com/group/spockframework';return true;" onclick="this.href='http://groups.google.com/group/spockframework';return true;" class="">http://groups.google.com/group/spockframework.
>> For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;" class="">https://groups.google.com/d/optout.
>
>
> --
> 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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="1he7lpmqvG0J" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;" class="">spockframewor...@googlegroups.com.
> To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="1he7lpmqvG0J" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;" class="">spockfr...@googlegroups.com.
> Visit this group at <a href="http://groups.google.com/group/spockframework" target="_blank" rel="nofollow" onmousedown="this.href='http://groups.google.com/group/spockframework';return true;" onclick="this.href='http://groups.google.com/group/spockframework';return true;" class="">http://groups.google.com/group/spockframework.
> For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;" class="">https://groups.google.com/d/optout.
>
>
> --
> 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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="1he7lpmqvG0J" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;" class="">spockframewor...@googlegroups.com.
> To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="1he7lpmqvG0J" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;" class="">spockfr...@googlegroups.com.
> Visit this group at <a href="http://groups.google.com/group/spockframework" target="_blank" rel="nofollow" onmousedown="this.href='http://groups.google.com/group/spockframework';return true;" onclick="this.href='http://groups.google.com/group/spockframework';return true;" class="">http://groups.google.com/group/spockframework.
> For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;" class="">https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/spockframework.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/spockframework.
For more options, visit https://groups.google.com/d/optout.

signature.asc (859 bytes) Download Attachment