Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

can't build domain class in Grails 2.1.4 app #1

Closed
ghost opened this issue Apr 19, 2013 · 8 comments
Closed

can't build domain class in Grails 2.1.4 app #1

ghost opened this issue Apr 19, 2013 · 8 comments

Comments

@ghost
Copy link

ghost commented Apr 19, 2013

I'm trying to use the v. 2.0.4 to build test data in a unit test of a Grails 2.1.4 application. The app has the following domain classes

class Brochure {
  static constraints = {}
  static hasMany = [pageTags: PageTag]    
}

class PageTag {
    static constraints = {
    }
    static belongsTo = [brochure: Brochure]
}

Then in my unit test I try to build an instance of PageTag with

@Build([Brochure, PageTag])
class BrochureTests {

    void testSomething() {
       PageTag pageTag = PageTag.build()
    }
}

But it fails with the error

groovy.lang.MissingMethodException: No signature of method: btd.bug.Brochure.addToPageTags() is applicable for argument types: (btd.bug.PageTag) values: [btd.bug.PageTag : (unsaved)] Possible solutions: getPageTags()

My example looks exactly the same as that shown in the plugin's docs, so I've no idea why this isn't working. A sample app that demonstrates the issue is available here

https://bitbucket.org/tednaleid/grails-test-data/issue-attachment/69/tednaleid/grails-test-data/1366373541.27/69/btd-bug.zip

@tednaleid
Copy link
Collaborator

Looks like grails 2.1.4 has a pretty big change to how they're mocking domain classes in unit tests. The release notes specify that you need to manually @Mock all domain classes that you want to work with.

I was able to get your test to pass by also calling @Mock on the domain classes in addition to @Build.

diff --git a/test/unit/btd/bug/BrochureTests.groovy b/test/unit/btd/bug/BrochureTests.groovy
index 2f2c03e..4502e2c 100644
--- a/test/unit/btd/bug/BrochureTests.groovy
+++ b/test/unit/btd/bug/BrochureTests.groovy
@@ -7,7 +7,8 @@ import org.junit.*
 /**
  * See the API for {@link grails.test.mixin.domain.DomainClassUnitTestMixin} for usage instructions
  */
-@Build([Brochure, PageTag])
+@Build([PageTag])
+@Mock([Brochure, PageTag])
 class BrochureTests {

     void testSomething() {

Not optimal, but apparently they did it for performance reasons. That change removes BTDs ability to "know" what classes are related to each other in unit tests and this is the unfortunate side effect. Integration tests should be fine, but for performance reasons the grails authors have made the decision to push the wiring knowledge onto the unit test to explicitly define.

@longwa
Copy link
Owner

longwa commented Apr 20, 2013

I believe this is fixed in the 2.0.5 RC that I've been testing. I'll merge it into master and push out a release next week. I should have done it awhile ago but have been sidetracked. The changes make BTD more friendly with some of the recent grails changes.

-Aaron

On Apr 19, 2013, at 8:52 PM, Ted Naleid notifications@github.com wrote:

Looks like grails 2.1.4 has a pretty big change to how they're mocking domain classes in unit tests. The release notes specify that you need to manually @mock all domain classes that you want to work with.

I was able to get your test to pass by also calling @mock on the domain classes in addition to @build.

diff --git a/test/unit/btd/bug/BrochureTests.groovy b/test/unit/btd/bug/BrochureTests.groovy
index 2f2c03e..4502e2c 100644
--- a/test/unit/btd/bug/BrochureTests.groovy
+++ b/test/unit/btd/bug/BrochureTests.groovy
@@ -7,7 +7,8 @@ import org.junit.*
/**

  • See the API for {@link grails.test.mixin.domain.DomainClassUnitTestMixin} for usage instructions
    */
    -@build([Brochure, PageTag])
    +@build([PageTag])
    +@mock([Brochure, PageTag])
    class BrochureTests {

    void testSomething() {
    Not optimal, but apparently they did it for performance reasons. That change removes BTDs ability to "know" what classes are related to each other in unit tests and this is the unfortunate side effect. Integration tests should be fine, but for performance reasons the grails authors have made the decision to push the wiring knowledge onto the unit test to explicitly define.


Reply to this email directly or view it on GitHub.

@longwa
Copy link
Owner

longwa commented Apr 20, 2013

I just tested the attached application with what is currently in the BTD develop branch and the test passes with no changes. The problem with 2.1.4 and later is that the mockDomain method changed in the grails mixins to take all fo the domains at once in order to optimize. BTD was always automatically mocking required, associated objects but in the new scheme those need to be determined entirely upfront and the newer method used or it doesn't seem to work properly. The latest code does that properly and is able to take advantage of the perf improvements in Grails at the same time.

Also, 2.0.5 fixes a number of other performance issues that were introduced in 2.0.3 and 2.0.4, mostly in unit tests.

@longwa
Copy link
Owner

longwa commented Apr 20, 2013

I pushed out a 2.0.5 release which fixes the issues you are seeing. Please upgrade and let me know if you still have problems.

@ghost
Copy link
Author

ghost commented Apr 20, 2013

thanks for addressing this so quickly, I'll check this out on Monday and report back here

@gregopet
Copy link
Contributor

Upgrading to 2.0.5 fixed my unit tests failing, as well. Good work and thank you!

@zyro23
Copy link

zyro23 commented Apr 26, 2013

while 2.0.5 reduced the number of errors i see, i still got some MissingMethodExceptions for MyDomain.addToMyHasManys(). anyhow, adding @mock for those makes it work.

@tednaleid
Copy link
Collaborator

Assuming this is fixed, please comment if there are still issues here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants