@InjectMocks behavior

[Chris Bartling]

I'm noticing some undocumented behavior with the @InjectMocks
annotation and I wanted to verify it with the authors of the
framework. The SUTs that I have been annotating with @InjectMocks
have been getting their dependencies injected into them without the
need for setter methods for the dependencies. I was rather surprised
by this behavior, as the documentation for the annotation specifies
that it only supports setter injection. Is this expected? If so, can
the documentation be updated to relay this behavior?

Thoughts?

Regards,

-- chris bartling --

[adrian....@googlemail.com]

I too have noticed this and a consequence is that it reduces your code
coverage (if you measure such things). I wonder if it uses the setters
to detect what to inject and then bypasses them, or simply uses
reflection to see which properties to inject and ignores the setters
completely. I'd prefer it if the setters were used properly as this is
more true to OO.

[szczepiq]

Well spotted! I think it makes sense what you guys are saying.

Any other opinions?

Cheers,
Szczepan Faber

--
You received this message because you are subscribed to the Google Groups "mockito" group.
To post to this group, send email to moc...@googlegroups.com.
To unsubscribe from this group, send email to mockito+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mockito?hl=en.

[Chris Bartling]

I'm favoring reflection-based DI behavior myself.  We use Spring and its annotations, using @Autowired and @Resource on the collaborator fields and never writing setters.  Certainly cleans up the code and its quite obvious what my collaborators are.  I don't know about the argument regarding OO.  I'm of the opinion that new language features and languages are helping to reduce code noise.  Incidentally, Groovy removes you from even writing setters and getters these days.  I personally like the reflection-based DI that @InjectMocks provides.  Perhaps in future versions it could be configurable?

-- chris --

[adrian....@googlemail.com]

I agree with all that as well, so maybe your original point about the
docs is the only thing that needs a slight amendment.

The other possibility is to use setters if they're there, otherwise
use the fields directly.

On Mar 19, 11:40 am, Chris Bartling <chris.bartl...@gmail.com> wrote:
> I'm favoring reflection-based DI behavior myself.  We use Spring and its
> annotations, using @Autowired and @Resource on the collaborator fields and
> never writing setters.  Certainly cleans up the code and its quite obvious
> what my collaborators are.  I don't know about the argument regarding OO.
>  I'm of the opinion that new language features and languages are helping to
> reduce code noise.  Incidentally, Groovy removes you from even writing
> setters and getters these days.  I personally like the reflection-based DI
> that @InjectMocks provides.  Perhaps in future versions it could be
> configurable?
>
> -- chris --
>

> On Fri, Mar 19, 2010 at 4:27 AM, szczepiq <szcze...@gmail.com> wrote:
> > Well spotted! I think it makes sense what you guys are saying.
>
> > Any other opinions?
>
> > Cheers,
> > Szczepan Faber
>

> >> mockito+u...@googlegroups.com<mockito%2Bunsu...@googlegroups.com>

> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/mockito?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "mockito" group.
> > To post to this group, send email to moc...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > mockito+u...@googlegroups.com<mockito%2Bunsu...@googlegroups.com>

[Malte Finsterwalder]

As a sidenote:

Another way to inject annotated attributes in tests is the EasyGloss Library:
https://easygloss.dev.java.net/
EasyGloss doesn't do any mock creation, just injection.
This gives you the freedom to choose what to inject.

Greetings,
Malte