Grails

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

Details

  • Type: Bug Bug
  • Status: Closed 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. File
    bad-mockfor.tgz
    02/Apr/12 2:50 PM
    179 kB
    J Pimmel
  2. GZip Archive
    mockfor-not-newed.tar.gz
    16/Apr/12 1:55 PM
    179 kB
    J Pimmel

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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

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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Vote (2)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: