As Dependency Injection frameworks go, the standard is currently CDI. When switching from Spring, one has to consider the following problem: how do you unit test your injected classes?
In Spring, DI is achieved through either constructor injection or setter injection. Both allow for simple unit testing by providing the dependencies and calling either the constructor or the desired setter. Now, how do you unit test the following code, which uses field injection:
public class MyMainClass {
@Inject
private MyDependencyClass dependency;
// dependency is used somewhere else
...
}Of course, there are some available options:
- you can provide a setter for the dependency field, just as you did in Spring
- you can use reflection to access the field
- you can use a testing framework that does the reflection for you (
PrivateAccessorfrom JUnit addons or Powermock come to mind) - you can increase the field visibility to package (i.e. default) and put the test case in the same package
Amazingly enough, when Googling through the web, the vast majority of unit testing field-injected classes code demonstrate the increased visibility.
Do a check if you do not believe me: they do not display the private visibility (here, here and here for example).
Granted, it’s a rather rethorical question, but what annoys me is that it’s implicit, whereas IMHO it should be a deeply thought-out decision.
My point is, changing design for testing purpose is like shooting yourself in the foot. Design shouldn’t be cheaply sold. Else, what will be the next step, changing your design for build purposes? Feels like a broken window to me. As long as it’s possible, I would rather stick to using the testing framework that enable private field-access. It achieves exactly the same purpose but at least it keeps my initial design.