Grails
  1. Grails
  2. GRAILS-8987

MockFor using during @TestFor annotated test (in Spock) seems to leak into subsequent tests

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Won't Fix
    • Affects Version/s: 2.0.1
    • Fix Version/s: 2.0.4
    • Component/s: Testing
    • Labels:
    • Environment:
      Linux, Ubuntu 10.4, Java 1.6.0_26-b03
    • Testcase included:
      yes

      Description

      This was originally reported some time back, as a ticket within the GSPOCK project (GPSPOCK-14); however it was suggested to be reported to Grails core.

      Description

      The attached project shows how using MockFor within tests - in this case Spock using @TestFor - appears to bleed that mock instance into a subsequent test that is trying to use the actual type unmocked.

      jerome@mofo:~/project/bad-mockfor$ grails test-app unit: toplevel.services.MehServiceSpec toplevel.controllers.BahControllerSpec
      Java HotSpot(TM) 64-Bit Server VM warning: Failed to reserve shared memory (errno = 22).
      | Completed 2 spock tests, 0 failed in 2957ms
      | Tests PASSED - view reports in target/test-reports
      
      jerome@mofo:~/project/bad-mockfor$ grails test-app unit: toplevel.controllers.BahControllerSpec toplevel.services.MehServiceSpec
      Java HotSpot(TM) 64-Bit Server VM warning: Failed to reserve shared memory (errno = 22).
      | Running 2 spock tests... 2 of 2
      | Failure:  it should delegate to other(toplevel.services.MehServiceSpec)
      |  junit.framework.AssertionFailedError: No more calls to 'getName' expected at this point. End of demands.
      	at toplevel.services.MehServiceSpec.it should delegate to other_closure2(MehServiceSpec.groovy:21)
      	at toplevel.services.MehServiceSpec.it should delegate to other(MehServiceSpec.groovy:20)
      | Completed 2 spock tests, 1 failed in 2864ms
      | Tests FAILED  - view reports in target/test-reports
      
      1. bad-mockfor.tgz
        179 kB
        J Pimmel
      2. mockfor-not-newed.tar.gz
        179 kB
        J Pimmel

        Activity

        Hide
        J Pimmel added a comment -
        Show
        J Pimmel added a comment - Meant to also add that this appears to be referenced by this thread http://grails.1312388.n4.nabble.com/Bad-groovy-MockFor-and-grails-UnitTestMixin-interaction-td4495633.html
        Hide
        J Pimmel added a comment -

        So I found then that the mock instance type bleed only happens when using the "new MockFor(Clazz)" convention.

        When I instead switched to the mockfor(Clazz) - which requires me to manage my own mock instance creation "someMockControl.createMock()" works around the problem fine.

        Hopefully that's a clue to however fixes this - see attached project where i have done just that

        Show
        J Pimmel added a comment - So I found then that the mock instance type bleed only happens when using the "new MockFor(Clazz)" convention. When I instead switched to the mockfor(Clazz) - which requires me to manage my own mock instance creation "someMockControl.createMock()" works around the problem fine. Hopefully that's a clue to however fixes this - see attached project where i have done just that
        Hide
        Haikal added a comment - - edited

        Seems to happen when using groovy.mock.interceptor.StubFor in grails 2.0.3 as well. One test works. The next test complains about demands made in the previous test.

        Something like:

        void testOne {
         // StubFor(GregorianCalendar) {...}
        }
        
        void testTwo {
          def foo = GregorianCaledar.newInstance() // <-- Fails, because the previous test set up demands 
        }

        Fails with a

        |  junit.framework.AssertionFailedError: No more calls to 'newInstance' expected at this point. End of demands.

        edit Note that this is just a plain old junit test case. Worked in Grails 1.3.7.

        Show
        Haikal added a comment - - edited Seems to happen when using groovy.mock.interceptor.StubFor in grails 2.0.3 as well. One test works. The next test complains about demands made in the previous test. Something like: void testOne { // StubFor(GregorianCalendar) {...} } void testTwo { def foo = GregorianCaledar.newInstance() // <-- Fails, because the previous test set up demands } Fails with a | junit.framework.AssertionFailedError: No more calls to 'newInstance' expected at this point. End of demands. edit Note that this is just a plain old junit test case. Worked in Grails 1.3.7.
        Hide
        Angelo Veltens added a comment -

        Same issue here with Grails 2.0.3 and a @TestFor annotated unit test using new StubFor(...)

        Show
        Angelo Veltens added a comment - Same issue here with Grails 2.0.3 and a @TestFor annotated unit test using new StubFor(...)
        Hide
        Graeme Rocher added a comment -

        I can't reproduce with the attached applications in master, 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

        Show
        Graeme Rocher added a comment - I can't reproduce with the attached applications in master, 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
        Hide
        Jon Palmer added a comment -

        so is this fixed in 2.0.4? I have the same problem. The reason that many of us are using MockFor is that it supports mocking calls to the constructor. Is that fixed using mockFor?

        Show
        Jon Palmer added a comment - so is this fixed in 2.0.4? I have the same problem. The reason that many of us are using MockFor is that it supports mocking calls to the constructor. Is that fixed using mockFor?
        Hide
        Angelo Veltens added a comment -

        I agree with Jon Palmer. Or is their any way to let mockFor affect instances created via new-Operator?

        Show
        Angelo Veltens added a comment - I agree with Jon Palmer. Or is their any way to let mockFor affect instances created via new-Operator?

          People

          • Assignee:
            Graeme Rocher
            Reporter:
            J Pimmel
          • Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development