Issue #14 on hold

Automatically autowire WrapWithSpy and ReplaceWithMock annotated fields

James Kennard
created an issue

Appreciate this may be rejected... I'm inclined to think when using the WrapWithSpy and ReplaceWithMock annotations that the created spy/mock should be autowired to the field rather than requiring the Autowired annotation as well. So instead of:

private SomeBean someBean;

private SomeOtherBean someOtherBean;

You would only need:

private SomeBean someBean;

private SomeOtherBean someOtherBean;

To be honest I cannot think of an occasion when you would want to use the WrapWithSpy and ReplaceWithMock annotations and not autowire the fields.

Comments (8)

  1. szpak

    Mentioned situation may occur when you mock an underlying bean which is automatically injected within a been you use in your test (for example mocked DAO to prevent creation of a connection to a database when you use an object from a service layer in your test). Nevertheless it's quite rare and I agree that would be useful (and also I don't see any drawbacks in your proposal).

  2. James Kennard reporter

    Hey szpak,

    Thanks for the example sceanrio, however that would surely only apply in the case of a mock?

    Your example with the DAO makes sense but I would not have thought that would constitute good practice. If you were mocking the DAO to prevent editing of a datasource then you would almost certainly want to define some givens/whens for that DAO. (The thought of this sounds nasty to me, it suggests you would be connecting to some datasource that wasn't specifically for testing - I digress). Or if you were always expecting nulls in response then surely you would want to verify interaction with the DAO? Perhaps if you could supply an Answer such as Answers.RETURNS_DEEP_STUBS this would make more sense.

    But as you say, it would seem harmless to autowire these in the event that you don't actually wish to do anything with them.

  3. kubek2k repo owner

    please take a look at:

    it adds a new bean post processor to the created context, that by default autowires dependencies. The downside of that is it's impossible to stop it - you can't add a custom logic that might decided if we want autowiring or not (eg. @ReplaceWithMock(autowire=false) is not doable this way).

    thanks for the response

  4. James Kennard reporter

    Hi kubek2k,

    Sorry for the very slow response. I am still planning on taking a look, I just haven't had a chance yet - hopefully I will get some time in the near future!


  5. Log in to comment