New approach to mocking domain classes in Grails unit tests

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

New approach to mocking domain classes in Grails unit tests

pledbrook
Hi,

As many of you know, the current implementation of mockDomain() does
not provide a full emulation of GORM. You can work around it by
mocking the methods that are missing, but that does mean a bit of
extra work and inconvenience.

There is now a new approach that does provide something close to full
emulation. It even supports criteria and named queries. Enabling it is
pretty straightforward. Start by adding these repository definitions
to BuildConfig.groovy:

    grails.project.dependency.resolution = {
        ...

        repositories {
            ...
            mavenRepo "http://maven.springframework.org/milestone"
            mavenRepo "http://snapshots.repository.codehaus.org"
        }
        ...
    }

Next, add the following annotation to your unit test:

    import grails.datastore.test.DatastoreUnitTestMixin

    @Mixin(DatastoreUnitTestMixin)
    class MyUnitTests extends GrailsUnitTestCase {
        ...
    }

You should probably add a call to disconnect() in your tearDown() method too:

    void tearDown() {
        disconnect()
        super.tearDown()
    }

mockDomain() will now emulate GORM much better than before.

One downside is that any test domain instances you pass to
mockDomain() must be valid. This can be quite a drag if you have a lot
of non-nullable properties in your domain class. The tests may run
slower too, but I haven't tested enough yet.

We would love people to give it a try and provide feedback. You can
easily revert the change by removing the annotation, so it's fairly
cheap to try it out.

Regards,

Peter

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: New approach to mocking domain classes in Grails unit tests

Dan Lynn
This looks great! Look forward to giving it a try.

Cheers,
Dan

On 09/07/2010 09:23 AM, Peter Ledbrook wrote:

> Hi,
>
> As many of you know, the current implementation of mockDomain() does
> not provide a full emulation of GORM. You can work around it by
> mocking the methods that are missing, but that does mean a bit of
> extra work and inconvenience.
>
> There is now a new approach that does provide something close to full
> emulation. It even supports criteria and named queries. Enabling it is
> pretty straightforward. Start by adding these repository definitions
> to BuildConfig.groovy:
>
>      grails.project.dependency.resolution = {
>          ...
>
>          repositories {
>              ...
>              mavenRepo "http://maven.springframework.org/milestone"
>              mavenRepo "http://snapshots.repository.codehaus.org"
>          }
>          ...
>      }
>
> Next, add the following annotation to your unit test:
>
>      import grails.datastore.test.DatastoreUnitTestMixin
>
>      @Mixin(DatastoreUnitTestMixin)
>      class MyUnitTests extends GrailsUnitTestCase {
>          ...
>      }
>
> You should probably add a call to disconnect() in your tearDown() method too:
>
>      void tearDown() {
>          disconnect()
>          super.tearDown()
>      }
>
> mockDomain() will now emulate GORM much better than before.
>
> One downside is that any test domain instances you pass to
> mockDomain() must be valid. This can be quite a drag if you have a lot
> of non-nullable properties in your domain class. The tests may run
> slower too, but I haven't tested enough yet.
>
> We would love people to give it a try and provide feedback. You can
> easily revert the change by removing the annotation, so it's fairly
> cheap to try it out.
>
> Regards,
>
> Peter
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>      http://xircles.codehaus.org/manage_email
>
>
>    


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: New approach to mocking domain classes in Grails unit tests

johnrellis
Great... less mocking is always good :)  will report any issues!

On Tue, Sep 7, 2010 at 5:59 PM, Dan Lynn <[hidden email]> wrote:
This looks great! Look forward to giving it a try.

Cheers,
Dan


On 09/07/2010 09:23 AM, Peter Ledbrook wrote:
Hi,

As many of you know, the current implementation of mockDomain() does
not provide a full emulation of GORM. You can work around it by
mocking the methods that are missing, but that does mean a bit of
extra work and inconvenience.

There is now a new approach that does provide something close to full
emulation. It even supports criteria and named queries. Enabling it is
pretty straightforward. Start by adding these repository definitions
to BuildConfig.groovy:

    grails.project.dependency.resolution = {
        ...

        repositories {
            ...
            mavenRepo "http://maven.springframework.org/milestone"
            mavenRepo "http://snapshots.repository.codehaus.org"
        }
        ...
    }

Next, add the following annotation to your unit test:

    import grails.datastore.test.DatastoreUnitTestMixin

    @Mixin(DatastoreUnitTestMixin)
    class MyUnitTests extends GrailsUnitTestCase {
        ...
    }

You should probably add a call to disconnect() in your tearDown() method too:

    void tearDown() {
        disconnect()
        super.tearDown()
    }

mockDomain() will now emulate GORM much better than before.

One downside is that any test domain instances you pass to
mockDomain() must be valid. This can be quite a drag if you have a lot
of non-nullable properties in your domain class. The tests may run
slower too, but I haven't tested enough yet.

We would love people to give it a try and provide feedback. You can
easily revert the change by removing the annotation, so it's fairly
cheap to try it out.

Regards,

Peter

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

    http://xircles.codehaus.org/manage_email


 


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

  http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: New approach to mocking domain classes in Grails unit tests

ld@ldaley.com
In reply to this post by pledbrook
Are your instructions missing that actual dependency declaration?

If not, how is it getting included?

On 08/09/2010, at 1:23 AM, Peter Ledbrook wrote:

> Hi,
>
> As many of you know, the current implementation of mockDomain() does
> not provide a full emulation of GORM. You can work around it by
> mocking the methods that are missing, but that does mean a bit of
> extra work and inconvenience.
>
> There is now a new approach that does provide something close to full
> emulation. It even supports criteria and named queries. Enabling it is
> pretty straightforward. Start by adding these repository definitions
> to BuildConfig.groovy:
>
>    grails.project.dependency.resolution = {
>        ...
>
>        repositories {
>            ...
>            mavenRepo "http://maven.springframework.org/milestone"
>            mavenRepo "http://snapshots.repository.codehaus.org"
>        }
>        ...
>    }
>
> Next, add the following annotation to your unit test:
>
>    import grails.datastore.test.DatastoreUnitTestMixin
>
>    @Mixin(DatastoreUnitTestMixin)
>    class MyUnitTests extends GrailsUnitTestCase {
>        ...
>    }
>
> You should probably add a call to disconnect() in your tearDown() method too:
>
>    void tearDown() {
>        disconnect()
>        super.tearDown()
>    }
>
> mockDomain() will now emulate GORM much better than before.
>
> One downside is that any test domain instances you pass to
> mockDomain() must be valid. This can be quite a drag if you have a lot
> of non-nullable properties in your domain class. The tests may run
> slower too, but I haven't tested enough yet.
>
> We would love people to give it a try and provide feedback. You can
> easily revert the change by removing the annotation, so it's fairly
> cheap to try it out.
>
> Regards,
>
> Peter
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: New approach to mocking domain classes in Grails unit tests

pledbrook
> Are your instructions missing that actual dependency declaration?
>
> If not, how is it getting included?

Just testing whether people were trying this out! Yes, the dependency
was missing, sorry:

    dependencies {
        test    "org.grails:grails-datastore-gorm-test:1.0.0.M1"

Peter

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: New approach to mocking domain classes in Grails unit tests

Sam Carr
In reply to this post by pledbrook

On 7 Sep 2010, at 16:23, Peter Ledbrook wrote:

> As many of you know, the current implementation of mockDomain() does
> not provide a full emulation of GORM. You can work around it by
> mocking the methods that are missing, but that does mean a bit of
> extra work and inconvenience.
>
> There is now a new approach that does provide something close to full
> emulation. ...

Peter - I tried out your cunning new DatastoreUnitTestMixin solution to mocking domain objects but I'm afraid get an error when I run my test:

groovy.lang.MissingMethodException: No signature of method: com.foo.User.addToCashTransactions() is applicable for argument types: (com.foo.CashTransaction) values: [com.foo.CashTransaction : null]
Possible solutions: addToCashTransactions(java.lang.Object), getCashTransactions()
        ...

My User domain class hasMany cashTransactions but it seems that the DatastoreUnitTestMixin has not mocked the dynamic addTo method successfully. The "possible solutions" bit of the error message confuses me as its first suggestion seems entirely applicable in this instance so I'm not sure why it was unhappy.

Sam

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: New approach to mocking domain classes in Grails unit tests

Ken Liu
Peter, didn't you tweet recently about not liking mixins? Is this one
of those cases?

On Thu, Sep 30, 2010 at 12:42 PM, Sam Carr <[hidden email]> wrote:

>
> On 7 Sep 2010, at 16:23, Peter Ledbrook wrote:
>
>> As many of you know, the current implementation of mockDomain() does
>> not provide a full emulation of GORM. You can work around it by
>> mocking the methods that are missing, but that does mean a bit of
>> extra work and inconvenience.
>>
>> There is now a new approach that does provide something close to full
>> emulation. ...
>
> Peter - I tried out your cunning new DatastoreUnitTestMixin solution to mocking domain objects but I'm afraid get an error when I run my test:
>
> groovy.lang.MissingMethodException: No signature of method: com.foo.User.addToCashTransactions() is applicable for argument types: (com.foo.CashTransaction) values: [com.foo.CashTransaction : null]
> Possible solutions: addToCashTransactions(java.lang.Object), getCashTransactions()
>        ...
>
> My User domain class hasMany cashTransactions but it seems that the DatastoreUnitTestMixin has not mocked the dynamic addTo method successfully. The "possible solutions" bit of the error message confuses me as its first suggestion seems entirely applicable in this instance so I'm not sure why it was unhappy.
>
> Sam
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: New approach to mocking domain classes in Grails unit tests

Sam Carr
In reply to this post by Sam Carr
> Peter - I tried out your cunning new DatastoreUnitTestMixin solution to mocking domain objects but I'm afraid get an error when I run my test:
>
> groovy.lang.MissingMethodException: No signature of method: com.foo.User.addToCashTransactions() is applicable for argument types: (com.foo.CashTransaction) values: [com.foo.CashTransaction : null]
> Possible solutions: addToCashTransactions(java.lang.Object), getCashTransactions()
> ...
>
> My User domain class hasMany cashTransactions but it seems that the DatastoreUnitTestMixin has not mocked the dynamic addTo method successfully. The "possible solutions" bit of the error message confuses me as its first suggestion seems entirely applicable in this instance so I'm not sure why it was unhappy.

Aha - I think have partly figured this out. The mixin doesn't add the mock methods to instances provided in the list to mockDomain(). My code does something like this, and barfs on the call to addToCashTransactions():

def fred = new User(name:"Fred")
def boris = new User(name:"Boris")
mockDomain(User, [fred, boris])

fred.addToCashTransactions(new CashTransaction(amount:5))
fred.save()

It seems that fred and boris never have the mock domain methods added to them. If I change it around to be as follows then it works (but I consider it a bug and don't want to have to do this):

mockDomain(User)
def fred = new User(name:"Fred").save()
def boris = new User(name:"Boris").save()

fred.addToCashTransactions(new CashTransaction(amount:5))
fred.save()

I suspect that actually something even more subtle is happening and that the Mixin has added the methods to my domain class (hence the confusing error message in my original email up top) but for some reason the existing instances aren't happy to call them.

Sam

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: New approach to mocking domain classes in Grails unit tests

Graeme Rocher
Administrator
On Fri, Oct 1, 2010 at 10:37 AM, Sam Carr <[hidden email]> wrote:

>> Peter - I tried out your cunning new DatastoreUnitTestMixin solution to mocking domain objects but I'm afraid get an error when I run my test:
>>
>> groovy.lang.MissingMethodException: No signature of method: com.foo.User.addToCashTransactions() is applicable for argument types: (com.foo.CashTransaction) values: [com.foo.CashTransaction : null]
>> Possible solutions: addToCashTransactions(java.lang.Object), getCashTransactions()
>>       ...
>>
>> My User domain class hasMany cashTransactions but it seems that the DatastoreUnitTestMixin has not mocked the dynamic addTo method successfully. The "possible solutions" bit of the error message confuses me as its first suggestion seems entirely applicable in this instance so I'm not sure why it was unhappy.
>
> Aha - I think have partly figured this out. The mixin doesn't add the mock methods to instances provided in the list to mockDomain(). My code does something like this, and barfs on the call to addToCashTransactions():
>
> def fred = new User(name:"Fred")
> def boris = new User(name:"Boris")
> mockDomain(User, [fred, boris])
>
> fred.addToCashTransactions(new CashTransaction(amount:5))
> fred.save()
>
> It seems that fred and boris never have the mock domain methods added to them. If I change it around to be as follows then it works (but I consider it a bug and don't want to have to do this):
>
> mockDomain(User)
> def fred = new User(name:"Fred").save()
> def boris = new User(name:"Boris").save()
>
> fred.addToCashTransactions(new CashTransaction(amount:5))
> fred.save()
>
> I suspect that actually something even more subtle is happening and that the Mixin has added the methods to my domain class (hence the confusing error message in my original email up top) but for some reason the existing instances aren't happy to call them.

Yeah this is a bug fixed with this commit
http://github.com/grails/inconsequential/commit/d6cf7aabbb685335775d38ca6ccd59d64e2690b9

Will be available in the next milestone

Cheers
Graeme

>
> Sam
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>



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


Reply | Threaded
Open this post in threaded view
|

Re: New approach to mocking domain classes in Grails unit tests

pledbrook
In reply to this post by Ken Liu
> Peter, didn't you tweet recently about not liking mixins? Is this one
> of those cases?

I don't remember doing so, but I may very well have done. What I will
say is that I think mixins are currently the right approach for adding
test behaviour. Providing super classes is just doesn't scale with the
number of frameworks that add extra features. For example, the Spock
plugin provides equivalents of GrailsUnitTestCase et al. simply
because the latter extend GroovyTestCase but Spock tests must extend
Spec. Add in the mock frameworks and mixins seem a far saner approach.

Peter

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: New approach to mocking domain classes in Grails unit tests

pledbrook
In reply to this post by Sam Carr
Thanks for trying this out Sam.

>> Peter - I tried out your cunning new DatastoreUnitTestMixin solution to mocking domain objects but I'm afraid get an error when I run my test:

Much as I'd like to take credit, this is Graeme's work.

> Aha - I think have partly figured this out. The mixin doesn't add the mock methods to instances provided in the list to mockDomain(). My code does something like this, and barfs on the call to addToCashTransactions():
>
> def fred = new User(name:"Fred")
> def boris = new User(name:"Boris")
> mockDomain(User, [fred, boris])
>
> fred.addToCashTransactions(new CashTransaction(amount:5))
> fred.save()
>
> It seems that fred and boris never have the mock domain methods added to them. If I change it around to be as follows then it works (but I consider it a bug and don't want to have to do this):
>
> mockDomain(User)
> def fred = new User(name:"Fred").save()
> def boris = new User(name:"Boris").save()
>
> fred.addToCashTransactions(new CashTransaction(amount:5))
> fred.save()
>
> I suspect that actually something even more subtle is happening and that the Mixin has added the methods to my domain class (hence the confusing error message in my original email up top) but for some reason the existing instances aren't happy to call them.

I was going to ask you to raise an issue, but Graeme's e-mail came
through as I was writing this :)

Peter

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: New approach to mocking domain classes in Grails unit tests

ld@ldaley.com
In reply to this post by pledbrook

On 01/10/2010, at 7:03 PM, Peter Ledbrook wrote:

>> Peter, didn't you tweet recently about not liking mixins? Is this one
>> of those cases?
>
> I don't remember doing so, but I may very well have done.

If you are referring to http://twitter.com/ldaley/status/24325690031 it was me.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: New approach to mocking domain classes in Grails unit tests

Sam Carr
In reply to this post by pledbrook
>
> As many of you know, the current implementation of mockDomain() does
> not provide a full emulation of GORM. You can work around it by
> mocking the methods that are missing, but that does mean a bit of
> extra work and inconvenience.
>
> There is now a new approach that does provide something close to full
> emulation....

I was hopeful that the new approach would respect the global failOnError config, but my testing seems to show that it does not. Perhaps I'm not setting things up correctly? The following test fails, using that mixin (and without it)

    void testRespectsFailOnErrorConfig() {
        mockDomain(User)
        ConfigurationHolder.config = new ConfigSlurper().parse("grails.gorm.failOnError = true")
        def invalidUser = new User()
        shouldFail(ValidationException) {
            invalidUser.save()
        }
    }

What do I need to do to see the results I was hoping for?

Also, the ValidationException thrown if insert a manual failOnError:true is org.springframework.datastore.validation.ValidationException rather than grails.validation.ValidationException, which is different behaviour to usual. Is that a bug?

Sam

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: New approach to mocking domain classes in Grails unit tests

Sam Carr
In reply to this post by pledbrook
> As many of you know, the current implementation of mockDomain() does
> not provide a full emulation of GORM. You can work around it by
> mocking the methods that are missing, but that does mean a bit of
> extra work and inconvenience.
>
> There is now a new approach that does provide something close to full
> emulation. It even supports criteria and named queries. Enabling it is
> pretty straightforward. Start by adding these repository definitions
> to BuildConfig.groovy:
>
>    grails.project.dependency.resolution = {
>        ...
>
>        repositories {
>            ...
>            mavenRepo "http://maven.springframework.org/milestone"
>            mavenRepo "http://snapshots.repository.codehaus.org"
>        }
>        ...
>    }

Having upgraded to Grails 1.3.5 (which may or may not be relevant) I now get dependency resolution issues and it takes 18 seconds or more to do dependency resolution, which used to take about 1 second:

                ::::::::::::::::::::::::::::::::::::::::::::::

                ::          UNRESOLVED DEPENDENCIES         ::

                ::::::::::::::::::::::::::::::::::::::::::::::

                :: commons-logging#commons-logging;1.1.1: not found

                :: javax.persistence#persistence-api;1.0: not found

                :: org.slf4j#slf4j-simple;1.5.8: not found

                ::::::::::::::::::::::::::::::::::::::::::::::

If I remove the "org.grails:grails-datastore-gorm-test:1.0.0.M1" dependency it goes away (but then I can't use DatastoreUnitTestMixin of course) so that's obviously somehow involved. I can't claim to understand the magic that goes on via Ivy - I thought it was supposed to banish dependency hell, but I seem to spend more time than ever struggling with problems like this. Sometimes I long for a libs directory full of jars that I put there and know work correctly :-)

A related question might be: is there an expectation for when the next grails-datastore-gorm-test milestone is likely to arrive?

Thanks

Sam


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: New approach to mocking domain classes in Grails unit tests

pledbrook
> If I remove the "org.grails:grails-datastore-gorm-test:1.0.0.M1" dependency it goes away (but then I can't use DatastoreUnitTestMixin of course) so that's obviously somehow involved. I can't claim to understand the magic that goes on via Ivy - I thought it was supposed to banish dependency hell, but I seem to spend more time than ever struggling with problems like this. Sometimes I long for a libs directory full of jars that I put there and know work correctly :-)

This can be done by adding a flatDir() repository. In fact, the 'lib'
directory should still work.

> A related question might be: is there an expectation for when the next grails-datastore-gorm-test milestone is likely to arrive?

I'll leave that to Graeme to answer.

Peter

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: New approach to mocking domain classes in Grails unit tests

Graeme Rocher
Administrator
In reply to this post by Sam Carr
On Tue, Oct 5, 2010 at 10:33 PM, Sam Carr <[hidden email]> wrote:

>> As many of you know, the current implementation of mockDomain() does
>> not provide a full emulation of GORM. You can work around it by
>> mocking the methods that are missing, but that does mean a bit of
>> extra work and inconvenience.
>>
>> There is now a new approach that does provide something close to full
>> emulation. It even supports criteria and named queries. Enabling it is
>> pretty straightforward. Start by adding these repository definitions
>> to BuildConfig.groovy:
>>
>>    grails.project.dependency.resolution = {
>>        ...
>>
>>        repositories {
>>            ...
>>            mavenRepo "http://maven.springframework.org/milestone"
>>            mavenRepo "http://snapshots.repository.codehaus.org"
>>        }
>>        ...
>>    }
>
> Having upgraded to Grails 1.3.5 (which may or may not be relevant) I now get dependency resolution issues and it takes 18 seconds or more to do dependency resolution, which used to take about 1 second:
>
>                ::::::::::::::::::::::::::::::::::::::::::::::
>
>                ::          UNRESOLVED DEPENDENCIES         ::
>
>                ::::::::::::::::::::::::::::::::::::::::::::::
>
>                :: commons-logging#commons-logging;1.1.1: not found
>
>                :: javax.persistence#persistence-api;1.0: not found
>
>                :: org.slf4j#slf4j-simple;1.5.8: not found
>
>                ::::::::::::::::::::::::::::::::::::::::::::::
>
> If I remove the "org.grails:grails-datastore-gorm-test:1.0.0.M1" dependency it goes away (but then I can't use DatastoreUnitTestMixin of course) so that's obviously somehow involved. I can't claim to understand the magic that goes on via Ivy - I thought it was supposed to banish dependency hell, but I seem to spend more time than ever struggling with problems like this. Sometimes I long for a libs directory full of jars that I put there and know work correctly :-)


You can do this to avoid the dependency resolve problems:

test( "org.grails:grails-datastore-gorm-test:1.0.0.M1") {
      excludes "persistence-api", "sl4j-simple", "commons-logging"
}
>
> A related question might be: is there an expectation for when the next grails-datastore-gorm-test milestone is likely to arrive?

The next milestone will probably be before SpringOne

Cheers

>
> Thanks
>
> Sam
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>



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


Reply | Threaded
Open this post in threaded view
|

Re: New approach to mocking domain classes in Grails unit tests

Luis Muniz-2
This is fantastic news guys, just when I think grails is pretty great you just pile on!



On Wed, Oct 6, 2010 at 11:27 AM, Graeme Rocher <[hidden email]> wrote:
On Tue, Oct 5, 2010 at 10:33 PM, Sam Carr <[hidden email]> wrote:
>> As many of you know, the current implementation of mockDomain() does
>> not provide a full emulation of GORM. You can work around it by
>> mocking the methods that are missing, but that does mean a bit of
>> extra work and inconvenience.
>>
>> There is now a new approach that does provide something close to full
>> emulation. It even supports criteria and named queries. Enabling it is
>> pretty straightforward. Start by adding these repository definitions
>> to BuildConfig.groovy:
>>
>>    grails.project.dependency.resolution = {
>>        ...
>>
>>        repositories {
>>            ...
>>            mavenRepo "http://maven.springframework.org/milestone"
>>            mavenRepo "http://snapshots.repository.codehaus.org"
>>        }
>>        ...
>>    }
>
> Having upgraded to Grails 1.3.5 (which may or may not be relevant) I now get dependency resolution issues and it takes 18 seconds or more to do dependency resolution, which used to take about 1 second:
>
>                ::::::::::::::::::::::::::::::::::::::::::::::
>
>                ::          UNRESOLVED DEPENDENCIES         ::
>
>                ::::::::::::::::::::::::::::::::::::::::::::::
>
>                :: commons-logging#commons-logging;1.1.1: not found
>
>                :: javax.persistence#persistence-api;1.0: not found
>
>                :: org.slf4j#slf4j-simple;1.5.8: not found
>
>                ::::::::::::::::::::::::::::::::::::::::::::::
>
> If I remove the "org.grails:grails-datastore-gorm-test:1.0.0.M1" dependency it goes away (but then I can't use DatastoreUnitTestMixin of course) so that's obviously somehow involved. I can't claim to understand the magic that goes on via Ivy - I thought it was supposed to banish dependency hell, but I seem to spend more time than ever struggling with problems like this. Sometimes I long for a libs directory full of jars that I put there and know work correctly :-)


You can do this to avoid the dependency resolve problems:

test( "org.grails:grails-datastore-gorm-test:1.0.0.M1") {
     excludes "persistence-api", "sl4j-simple", "commons-logging"
}
>
> A related question might be: is there an expectation for when the next grails-datastore-gorm-test milestone is likely to arrive?

The next milestone will probably be before SpringOne

Cheers
>
> Thanks
>
> Sam
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>



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



Reply | Threaded
Open this post in threaded view
|

Re: New approach to mocking domain classes in Grails unit tests

Sam Carr
In reply to this post by Graeme Rocher
>>> Having upgraded to Grails 1.3.5 (which may or may not be relevant) I now get dependency resolution issues and it takes 18 seconds or more to do dependency resolution, which used to take about 1 second:
>>>
>>>                ::::::::::::::::::::::::::::::::::::::::::::::
>>>
>>>                ::          UNRESOLVED DEPENDENCIES         ::
>>>
>>>                ::::::::::::::::::::::::::::::::::::::::::::::
>>>
>>>                :: commons-logging#commons-logging;1.1.1: not found
>>>
>>>                :: javax.persistence#persistence-api;1.0: not found
>>>
>>>                :: org.slf4j#slf4j-simple;1.5.8: not found
>>>
>>>                ::::::::::::::::::::::::::::::::::::::::::::::
>>>
>>> If I remove the "org.grails:grails-datastore-gorm-test:1.0.0.M1" dependency it goes away (but then I can't use DatastoreUnitTestMixin of course) so that's obviously somehow involved. I can't claim to understand the magic that goes on via Ivy - I thought it was supposed to banish dependency hell, but I seem to spend more time than ever struggling with problems like this. Sometimes I long for a libs directory full of jars that I put there and know work correctly :-)
>>
>>
>> You can do this to avoid the dependency resolve problems:
>>
>> test( "org.grails:grails-datastore-gorm-test:1.0.0.M1") {
>>      excludes "persistence-api", "sl4j-simple", "commons-logging"
>> }

Thanks Graeme - works nicely, though there's a minor typo: it needs an f in slf4j. I only mention that in case anyone else is following along and it's not working for them.

Resolving dependencies now takes about 10 seconds though, whereas it used to be about 1s. I've never understood why it takes any more than 0s, if I haven't changed BuildConfig. Surely it has everyone it needs and doesn't need to do anything if the config files haven't been changed since last time it ran? I've never understood this and it's always frustrated me as it should be instantaneous 99% of the time. Obviously I have missed an important point in understanding what's going on and why, but somebody needs to clue me in to what it is.

Thanks

Sam

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: New approach to mocking domain classes in Grails unit tests

John Fletcher-3
In reply to this post by Graeme Rocher
2010/10/6 Graeme Rocher
On Tue, Oct 5, 2010 at 10:33 PM, Sam Carr <[hidden email]> wrote:> A related question might be: is there an expectation for when the next grails-datastore-gorm-test milestone is likely to arrive?

The next milestone will probably be before SpringOne


I've been following this thread with interest. Does the above comment mean that this will be in Grails 1.3.6? By the way, I wanted to have a look at the milestone builds out of interest and found I was unable to follow the instructions at http://www.grails.org/Download to get a development build. The instructions don't line up with what is found at hudson.grails.org.

John.
Reply | Threaded
Open this post in threaded view
|

Re: New approach to mocking domain classes in Grails unit tests

Graeme Rocher
Administrator
On Mon, Nov 8, 2010 at 6:11 PM, John Fletcher <[hidden email]> wrote:

> 2010/10/6 Graeme Rocher
>>
>> On Tue, Oct 5, 2010 at 10:33 PM, Sam Carr <[hidden email]> wrote:> A
>> related question might be: is there an expectation for when the next
>> grails-datastore-gorm-test milestone is likely to arrive?
>>
>> The next milestone will probably be before SpringOne
>>
>
> I've been following this thread with interest. Does the above comment mean
> that this will be in Grails 1.3.6? By the way, I wanted to have a look at
> the milestone builds out of interest and found I was unable to follow the
> instructions at http://www.grails.org/Download to get a development build.
> The instructions don't line up with what is found at hudson.grails.org.

You don't need to build Grails to try out the new mocking stuff since
it exists in a separate project at
https://github.com/grails/inconsequential

You can clone that from Git and install it into your local maven repo using

./gradlew install

From their you can enable the mavenLocal() repo in BuildConfig of your
Grails project then add this dependency:

test( "org.grails:grails-datastore-gorm-test:1.0.0.BUILD-SNAPSHOT") {
     excludes "persistence-api", "sl4j-simple", "commons-logging"
}

Cheers
>
> John.
>



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


12