Should you change your design for testing purposes?

I also would use less restricted visibility if I had to (to default, i.e. package private), I consider using reflection for this really silly, and introducing a framework just for that purpose even more so. My biggest headache here is that you are looking for the problem in the wrong place. You are preaching clean design, but you are using field injection, which is the actual problem and a smell. Multiple blogs and even the specs mention this as a quick prototyping support and a way to make code less verbose for snippets and tutorials. In production code you should _never, ever_ do field injection. What does it buy you? Such injection is actually done when the instance is created, which is the pretty much the same time when a constructor is called, but it has a couple of main drawbacks: a) as you noticed, it is not as trivial to test the class as with constructor injection b) the fields cannot be final any more Change your design to constructor injection and get final fields as a bonus. Additionally, it is documented clearly what your class / bean / service requires to work correctly. I know setter injection is sometimes a must, and then you don't have final fields any more, but still, field injection is the worst option of them all.

I also agree that this subject keeps coming up, however, (C)DI in a JEE environnent is a bit different than the rest...

If you use constructor injection, what happens when the Bean is migrated to another server in the cluster?

The dependency that was previously injected (ie. DAOs, Entitymanger, etc. pp.) might not even exist on this server, or another instance exists for that server... the CDI spec imposes some restrictions to constructor injection for a reason, the only valid alternatives are setter injection and field injection, since the container must be able to replace previously injected dependencies after serializing a bean to another server in the cluster.

Setter injection is flexible but introduces additional methods to the code, filed injection requires some magic in tests...

Use constructor injection for the must-have dependencies, but use setter injection for the optional dependencies and fallback elegantly when they are not provided. Field injection should be prohibited. At first look it might be helpful, but it's hurting the readability: it does not express dependencies clearly.

I don't understand. If it's part of the requirements that some dependencies can or must be replaced, than it's needs to be a part of the design, too.

So if the requirement from the UI team is that some dependencies have to be replaced, which are expensive to create (like when the user switches modules) than why are you reluctant to add a setter method that clearly states the requirement in the design?

 For example, in Swing we have the same like JScrollPane#setHorizontalScrollBar. Normally I would say the horizontal scroll bar is a final-dependency, because without the JScollPane is useless. But there are requirements to change the scroll bar at run-time, so there is a setter method.

You can even easily  communicate the indent of the setter method:

/**
* Used by the UI team to replace the dependency if the user switches a module.
*/
@Inject
void setDependency(Dependency newDependency) { }

@Wujek

 Okay, then it looks like the design of your app implies the existence of the setters. But would you still consider setter injection a better choice than field injection if your injection framework was capable of replacing the dependencies of the existing objects at runtime?

e.g.
MyFramework.take(anObjectFromPool).andInject(anotherDependency.class, yetAnotherDependency.class).

In other words, is it a good idea to change your design (namely: to create setters) in any case when using a dependency injection framework? Would you publish those setters via a public interface? What visibility would those setters get anyhow?
And what about the constructor injection pattern, should the ctors be public if their only explicit clients are tests (and the DI framework of course, via some extralinguistic mechanisms though)?