Groovy MockFor strongly discouraged?

[redcoat]

Hi,

Been fighting a mocking issue where I had to mock an object that is created within a method at runtime.  While searching for a solution (we're using the Grails Spock plugin) I came across this: http://jira.grails.org/browse/GRAILS-8987?attachmentOrder=desc in which Graeme Rocher makes the following comment: "...however MockFor and StubFor from Groovy are strongly discouraged in favor of the build in mockFor method that is part of all unit tests in Grails"

I don't believe the Grails mockFor() can handle the above situation, as there is no way to set the mock on the service?  If not, what are the ramifications of using Groovy's MockFor - it seems to be working well for me.

cheers,

David

[Graeme Rocher-4]

It might leak changes between tests, you may have to manually cleanup
meta class changes

On Wed, Jul 18, 2012 at 4:24 PM, David Hay <[hidden email]> wrote:

> Hi,
>
> Been fighting a mocking issue where I had to mock an object that is created
> within a method at runtime.  While searching for a solution (we're using the
> Grails Spock plugin) I came across this:
> http://jira.grails.org/browse/GRAILS-8987?attachmentOrder=desc in which
> Graeme Rocher makes the following comment: "...however MockFor and StubFor
> from Groovy are strongly discouraged in favor of the build in mockFor method
> that is part of all unit tests in Grails"
>
> I don't believe the Grails mockFor() can handle the above situation, as
> there is no way to set the mock on the service?  If not, what are the
> ramifications of using Groovy's MockFor - it seems to be working well for
> me.
>
> cheers,
>
> David
>
>
>

--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[redcoat]

Am I right that I don't have any other options in this situation, where there is no way to set the mock on the Service.

I am now hitting the leaked changes in my integration tests :(  What is the best way to clean up the changes I make with Groovy's MockFor?  Apparently in Spock Specification there is no registerMetaClass() method.

cheers,

David

On Thu, Jul 19, 2012 at 3:30 AM, Graeme Rocher <[hidden email]> wrote:

It might leak changes between tests, you may have to manually cleanup
meta class changes

On Wed, Jul 18, 2012 at 4:24 PM, David Hay <[hidden email]> wrote:
> Hi,
>
> Been fighting a mocking issue where I had to mock an object that is created
> within a method at runtime.  While searching for a solution (we're using the
> Grails Spock plugin) I came across this:
> http://jira.grails.org/browse/GRAILS-8987?attachmentOrder=desc in which
> Graeme Rocher makes the following comment: "...however MockFor and StubFor
> from Groovy are strongly discouraged in favor of the build in mockFor method
> that is part of all unit tests in Grails"
>
> I don't believe the Grails mockFor() can handle the above situation, as
> there is no way to set the mock on the service?  If not, what are the
> ramifications of using Groovy's MockFor - it seems to be working well for
> me.
>
> cheers,
>
> David
>
>
>

--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Brian Doyle]

We've had so many leaks and it's hard to debug, we decided to just run
the unit and integration tests separately.  They have very different
ways of handling mocking that it makes sense.

I gave up on registerMetaClass in the unit tests and was hoping to
hear if there is a better way.  The MockFor seems to leak in the unit
tests themselves which is not what I would expect.

On Thu, Aug 16, 2012 at 12:37 PM, David Hay <[hidden email]> wrote:

> Am I right that I don't have any other options in this situation, where
> there is no way to set the mock on the Service.
>
> I am now hitting the leaked changes in my integration tests :(  What is the
> best way to clean up the changes I make with Groovy's MockFor?  Apparently
> in Spock Specification there is no registerMetaClass() method.
>
> cheers,
>
> David
>
> On Thu, Jul 19, 2012 at 3:30 AM, Graeme Rocher <[hidden email]> wrote:
>>
>> It might leak changes between tests, you may have to manually cleanup
>> meta class changes
>>
>> On Wed, Jul 18, 2012 at 4:24 PM, David Hay <[hidden email]> wrote:
>> > Hi,
>> >
>> > Been fighting a mocking issue where I had to mock an object that is
>> > created
>> > within a method at runtime.  While searching for a solution (we're using
>> > the
>> > Grails Spock plugin) I came across this:
>> > http://jira.grails.org/browse/GRAILS-8987?attachmentOrder=desc in which
>> > Graeme Rocher makes the following comment: "...however MockFor and
>> > StubFor
>> > from Groovy are strongly discouraged in favor of the build in mockFor
>> > method
>> > that is part of all unit tests in Grails"
>> >
>> > I don't believe the Grails mockFor() can handle the above situation, as
>> > there is no way to set the mock on the service?  If not, what are the
>> > ramifications of using Groovy's MockFor - it seems to be working well
>> > for
>> > me.
>> >
>> > cheers,
>> >
>> > David
>> >
>> >
>> >
>>
>>
>>
>> --
>> Graeme Rocher
>> Grails Project Lead
>> SpringSource - A Division of VMware
>> http://www.springsource.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>

--
Brian Doyle
Director of Engineering @ Closely
1822 Blake St.
Denver, CO 80202
@brian_doyle - Twitter

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Nathan Wells]

I'd suggest refactoring the code: either make it so that creating your object can be tested as part of the unit test, or factor out the object creation code and inject the object into the method as a parameter. This will allow you to test the code independent of the object's creation.

I'm afraid, though, that this comment won't seem helpful to you. You probably want to be able to write tests independent of the structure of your code. Sadly, this isn't possible with any testing library. If you'd like to post code samples, I could give you more specific ideas on how to refactor.

Thanks,
Nathan Wells

On Thu, Aug 16, 2012 at 12:53 PM, Brian Doyle <[hidden email]> wrote:

We've had so many leaks and it's hard to debug, we decided to just run
the unit and integration tests separately.  They have very different
ways of handling mocking that it makes sense.

I gave up on registerMetaClass in the unit tests and was hoping to
hear if there is a better way.  The MockFor seems to leak in the unit
tests themselves which is not what I would expect.

On Thu, Aug 16, 2012 at 12:37 PM, David Hay <[hidden email]> wrote:
> Am I right that I don't have any other options in this situation, where
> there is no way to set the mock on the Service.
>
> I am now hitting the leaked changes in my integration tests :(  What is the
> best way to clean up the changes I make with Groovy's MockFor?  Apparently
> in Spock Specification there is no registerMetaClass() method.
>
> cheers,
>
> David
>
> On Thu, Jul 19, 2012 at 3:30 AM, Graeme Rocher <[hidden email]> wrote:
>>
>> It might leak changes between tests, you may have to manually cleanup
>> meta class changes
>>
>> On Wed, Jul 18, 2012 at 4:24 PM, David Hay <[hidden email]> wrote:
>> > Hi,
>> >
>> > Been fighting a mocking issue where I had to mock an object that is
>> > created
>> > within a method at runtime.  While searching for a solution (we're using
>> > the
>> > Grails Spock plugin) I came across this:
>> > http://jira.grails.org/browse/GRAILS-8987?attachmentOrder=desc in which
>> > Graeme Rocher makes the following comment: "...however MockFor and
>> > StubFor
>> > from Groovy are strongly discouraged in favor of the build in mockFor
>> > method
>> > that is part of all unit tests in Grails"
>> >
>> > I don't believe the Grails mockFor() can handle the above situation, as
>> > there is no way to set the mock on the service?  If not, what are the
>> > ramifications of using Groovy's MockFor - it seems to be working well
>> > for
>> > me.
>> >
>> > cheers,
>> >
>> > David
>> >
>> >
>> >
>>
>>
>>
>> --
>> Graeme Rocher
>> Grails Project Lead
>> SpringSource - A Division of VMware
>> http://www.springsource.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>

--
Brian Doyle
Director of Engineering @ Closely
1822 Blake St.
Denver, CO 80202
@brian_doyle - Twitter

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[barnesjd]

Nathan Wells wrote

... You probably want to be able to write tests independent of the structure of your code. Sadly, this isn't possible with any testing library...

I disagree.  Have you tried JMockIt?  I've not tried it in the Grails environment, but it works great in a plain Java environment.  I'm using it at work and you can mock out constructors, final methods, static methods, everything.  It basically swaps out the byte code at run time.  It has been REALLY good for mocking out nasty wads of legacy code that I typically deal with.

[Nathan Wells]

Sorry, I shouldn't have painted with such a broad brush. I've never tried JMockIt. I was speaking from my experience with what I used with Grails.
Nathan Wells

On Fri, Aug 17, 2012 at 9:12 PM, barnesjd <[hidden email]> wrote:

Nathan Wells wrote
>
> ... You probably want to be able to write tests independent of the

> structure of your code. Sadly, this isn't possible with any testing

> library...
>

I disagree.  Have you tried JMockIt?  I've not tried it in the Grails
environment, but it works great in a plain Java environment.  I'm using it
at work and you can mock out constructors, final methods, static methods,
everything.  It basically swaps out the byte code at run time.  It has been
REALLY good for mocking out nasty wads of legacy code that I typically deal
with.



--
View this message in context: http://grails.1312388.n4.nabble.com/Groovy-MockFor-strongly-discouraged-tp4631743p4633403.html
Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Antony Jones]

I can recommend SpockMock which is built into spock. It handles most
cases. For those it doesn't, try GMock, but make sure to test-scope
it, as you'll have some very strange issues otherwise.

Cheers,
Antony

On 19 August 2012 03:56, Nathan Wells <[hidden email]> wrote:

> Sorry, I shouldn't have painted with such a broad brush. I've never tried
> JMockIt. I was speaking from my experience with what I used with Grails.
> Nathan Wells
>
>
>
> On Fri, Aug 17, 2012 at 9:12 PM, barnesjd <[hidden email]> wrote:
>>
>>
>> Nathan Wells wrote
>> >
>> > ... You probably want to be able to write tests independent of the
>> > structure of your code. Sadly, this isn't possible with any testing
>> > library...
>> >
>>
>> I disagree.  Have you tried JMockIt?  I've not tried it in the Grails
>> environment, but it works great in a plain Java environment.  I'm using it
>> at work and you can mock out constructors, final methods, static methods,
>> everything.  It basically swaps out the byte code at run time.  It has
>> been
>> REALLY good for mocking out nasty wads of legacy code that I typically
>> deal
>> with.
>>
>>
>>
>> --
>> View this message in context:
>> http://grails.1312388.n4.nabble.com/Groovy-MockFor-strongly-discouraged-tp4631743p4633403.html
>> Sent from the Grails - user mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>

--
________________________________
ꜽ . antony jones . http://www.enzy.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[New Groovy]

What is the suggested way to "test-scope it"?

On Mon, Aug 20, 2012 at 1:54 PM, Antony Jones <[hidden email]> wrote:

I can recommend SpockMock which is built into spock. It handles most
cases. For those it doesn't, try GMock, but make sure to test-scope
it, as you'll have some very strange issues otherwise.

Cheers,
Antony

On 19 August 2012 03:56, Nathan Wells <[hidden email]> wrote:
> Sorry, I shouldn't have painted with such a broad brush. I've never tried
> JMockIt. I was speaking from my experience with what I used with Grails.
> Nathan Wells
>
>
>
> On Fri, Aug 17, 2012 at 9:12 PM, barnesjd <[hidden email]> wrote:
>>
>>
>> Nathan Wells wrote
>> >
>> > ... You probably want to be able to write tests independent of the
>> > structure of your code. Sadly, this isn't possible with any testing
>> > library...
>> >
>>
>> I disagree.  Have you tried JMockIt?  I've not tried it in the Grails
>> environment, but it works great in a plain Java environment.  I'm using it
>> at work and you can mock out constructors, final methods, static methods,
>> everything.  It basically swaps out the byte code at run time.  It has
>> been
>> REALLY good for mocking out nasty wads of legacy code that I typically
>> deal
>> with.
>>
>>
>>
>> --
>> View this message in context:
>> http://grails.1312388.n4.nabble.com/Groovy-MockFor-strongly-discouraged-tp4631743p4633403.html
>> Sent from the Grails - user mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>

--
________________________________
ꜽ . antony jones . http://www.enzy.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email