Issue #24 new

SpringockitoContextLoader not compatible with spring 3.2.0-RELEASE

Anonymous avatarAnonymous created an issue

I'm using springockito-annotations that stopped working since spring 3.2.0-RELEASE. In spring 3.1.0-RELEASE there was following method call order initiated from TestContext constructor on contextLoader :

SpringockitoContextLoader#modifyLocations SpringockitoContextLoader#generateDefaultLocations

whereas in spring 3.2.0-RELEASE it is :

SpringockitoContextLoader#generateDefaultLocations SpringockitoContextLoader#modifyLocations

Now the problem is that modifyLocations methods is passed the Class A where ContextConfiguration locations are defined whereas generateDefaultLocations method is passed the actual Test Class B having fields mocked (considering that our Test class B extends the class A).

As a result there are no mockedBeans found because you don't Map#putAll, but only

this.mockedBeans = mockedBeansFinder.findMockedBeans(clazz);

in both methods....

The easiest fix would be having :

this.mockedBeans.putAll(mockedBeansFinder.findMockedBeans(clazz));

Comments (10)

  1. lisak

    In other words, Class A (with mocks) has no locations specified, so generateDefaultLocations on that class.

    Then process locations on Class B (A extends B) that has locations specified, so modifyLocations on that class. But at this point you throw away all the mocks you collected on Class A. Because of using this assignment instead of Map#putAll();

    this.mockedBeans = mockedBeansFinder.findMockedBeans(clazz);

  2. lisak

    You can close it. I cloned the repo to fix it, finding it's been already fixed. You might want to update springockito wiki... considering there's 1.0.7 version out there.

  3. lisak

    Although it has one flaw now. If class B (B extends A) doesn't declare @ContextConfiguration as class A does, then @ReplaceWithMock doesn't mock underlying field. So for Springockito-annotation to work in child classes they must always declare @ContextConfiguration no matter if it is defined in their ancestor already.

  4. lisak

    Now the weird stuff, I noticed that mocking beans via annotation @ReplaceWithMock produces mocks that behave differently than if I use <mockito:mock id="myBean" class="MyBean" />....

    Tested on : when(myBean.myMethod(anyLong(), anyString())).thenReturn(smth);

    It works only if I use @ReplaceWithMock. If I use the oldschool xml way, I get InvalidUseOfMatchersException and the only way it runs is by not using Matchers :

    when(myBean.myMethod(1L, "smth")).thenReturn(smth);

  5. pbatko

    I think the problem is that in 'springockito' org.kubek2k.mockito.spring.factory.MockFactoryBean#getObject method uses such statement to create mock:

    "instance = ClassImposterizer.INSTANCE.imposterise(new ThreadLocalMockMethodInterceptor<T>(mockClass), mockClass, new Class[0]);"

    whereas the same method from 'springockito-annatotions' uses:

    "instance = Mockito.mock(mockClass);".

    The former solution creates mocks that org.mockito.cglib.proxy.MethodInterceptor but org.mockito.internal.util.MockUtil#isMock method expects mock to extend org.mockito.internal.creation.MethodInterceptorFilter class.

    Edit: I noticed that I'm using 'springockito-annatations' 1.02 that isn't the newest version. My description applies to 'springockito-annatations' 1.02. However, my remarks concerning 'springockito' were made based on current 1.05 version.

  6. kubek2k

    heh - yeah - it looks like the try to make the multithreaded testing framing spoil it all. pbatko Glad that You forked that, since I don't have that much time to take a look.

  7. pbatko

    lisak - let's call the problem with needing to declare @ContextConfiguration in subclasses a feature and not a bug ;). It's really spring dependent as @SpringockitoContextLoader which scans for springockito annatated fields is given (by spring) only classes marked with the @ContextConfiguration.

    As for the initial issue seems like it was fixed some time ago.. And for the problem with stubbing mocks it should also work with current revision. Hope we'll get next release this week ;).

  8. pbatko

    Both problem with connected with order of invocations of modifyLocations/generateDefaultLocations methods and of stubbing mocks are hopefully fixed in current release. If no further related issues will be reported, I'll close this jira in a few days time.

  9. Log in to comment
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.