0

Does ZK SpringUtil.getBean come with a warning about unit testing?

asked 2013-07-25 12:18:24 +0800

Crow gravatar image Crow
3 2

I've stumbled upon code that does SpringUtil.getBean instead of passing in the bean via injection (setter or constructor).

It's not my code and I'd prefer to inject for unit testing reasons. Does this approach come with a warning about making it difficult to unit test (specifically mocking?)

delete flag offensive retag edit

2 Answers

Sort by ยป oldest newest most voted
0

answered 2013-07-26 02:45:59 +0800

cor3000 gravatar image cor3000
6280 2 7

Looking at the source code of SpringUtil I see no warning. SpringUtil is used by the ZK's injection mechanism (by DelegatingVariableResolver) so a warning would also be thrown if you used @WireVariable annotations, which is not desirable.

link publish delete flag offensive edit
0

answered 2014-04-01 19:09:53 +0800

Crow gravatar image Crow
3 2

updated 2014-04-01 19:50:00 +0800

Reading a bit about dependency injection on Stack Overflow (I can't post links so look for 'what is dependency injection?' and 'Dependency Inject vs factory pattern') I get several pieces of information about DI that makes me question the assertion that this is dependency injection.

Attributes of dependency injection include:

  • An object is not responsible for creating objects
  • An object is not responsible for obtaining the objects it needs
  • An object does not know how it get's it's required objects.


While the first criteria is true I don't see that the last two would be true if I used SpringUtil.getBean(). In this case, the class using it is responsible for obtaining it's dependencies and has to get them itself.

It appears the Zk Framework does assist to provide that dependency and keeps a copy of the bean, however if I use the SpringUtil.getBean() method my class still has the responsibility to obtain the bean.

It seems to me with that, the Hollywood principle demonstrates how this approach does break dependency injection. For those who don't know that principle is 'Don't call us, we'll call you'. In my interpretation that mean don't be responsible for calling to get the objects you need - have them given to you.

One further problem with this is that I find the class is not clear about it's required dependencies. I don't think it's clear requirement but being able to create or obtain objects inside a method of an object means the class isn't clear with it's outside world about what dependencies it requires

link publish delete flag offensive edit

Comments

I don't know exactly what you are trying to tell, if you use @WireVariable you are not breaking the dependency injection principles in your class. The thing is at some place the Annotation has to be parsed and resolved, that's what DelegatingVarible resolver is doing, not you in your class.

cor3000 ( 2014-04-25 03:41:10 +0800 )edit
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!

[hide preview]

Question tools

Follow
1 follower

RSS

Stats

Asked: 2013-07-25 12:18:24 +0800

Seen: 24 times

Last updated: Apr 01 '14

Support Options
  • Email Support
  • Training
  • Consulting
  • Outsourcing
Learn More