And Misko is one of the heroes of this topic. I think there is not much of a guy like him that still insists on testable codes rather than unit testing :)

Also for the other commenters, if you want more info on writing testable code, and why DI really helps then check out Misko Hevery’s Clean Code talks – http://misko.hevery.com/2008/11/04/clean-code-talks-unit-testing/

I would like to find a good text that explains how DI helps make code more modular or maintainable. What I have seen so far leads me to believe that DI often is detrimental to OO design.

Specifically, developers tend to make service classes stateless instead of stateful, so they can be singletons. This is not good design. I prefer to favor stateful service classes, with instance lifetimes limited to the business operations that rely on them. Such instances are typically created with context-specific data, usually coming from the UI. Using DI would prevent me from doing this. Also, DI requires dependencies that would otherwise be private to be publicy exposed; this violates the information hiding principle. And lets not forget about the KISS and YAGNI principles.

A good example of DI abuse is the DDD sample application. It can be simplified a lot, without any obvious loss in design qualities. I actually intend to create a JMockit-based version of it when I get the time, as another sample for the toolkit.

About your concerns with DI vs in-method dependencies, both side has its own advantages and disadvantages. We can’t put a silver bullet rule for all conditions. My experience with DI tells me good things rather than its complexity. However I agree that if you’re using Spring sort of frameworks you might end up having lots of interfaces or setter methods which you’ll never need. I already mentioned this problem in one of my previous article (@see Naming Java Implementation Classes). Then again to me creating a nice dependency mechanism makes code much more readable and easy to understand. The quantity of your java classes or methods doesn’t matter, I think having clean code is very important. And without DI or principles/patterns, people feel themselves so free and goes into procedural programming rather than OOP. And following these sort of principles/patterns keeps the conventions. When you see a code that uses these conventions, it’s really not hard to adapt it. But as I said, both usages have their own benefits. I can’t argue about it although I feel myself more comfortable in the DI side.

How easy it is to unit test a piece should only depend on its intrinsic complexity, not on accidental characteristics. For example, it should not matter if the code makes use of constructors, final classes/methods, static methods, or whatever. These are all perfectly valid Java language features and idioms.

The problem with using DI (or any other principle or pattern) for the sake of unit testing is that it will tend to make the code more complex, often with pointless interfaces/abstractions, “setter methods”, “wiring configuration”, etc. that only add noise to the codebase.

Clean, short and elegant unit tests can be written for any production code, depending only on the essential complexity of the tested code. DI really only adds complexity, not reduces it.

Doing this in real-world projects has nothing to do with how knowledgeable a developer is. The developers will need to learn the mocking API, that’s all. Compare that to learning Guice or Spring IOC.

@rogerio, problem is not about can/cannot test the code. It’s ‘how easy‘ to test the code. The assumption is generally declared like that to actually describe this situation. Just think like this, if your constructor or any of your method does amazing job in its implementation by keeping all in-method dependencies, maybe a developer could do some testing using his/her advanced knowledge. However do you think is this really required to do a simple unit testing? Or is there a major need to make your code this much complicated? To me there are couple issues here. First it makes harder for the next developer to adapt the code! Second it’s very hard to maintain ‘coz lots of things have in-method dependencies. And third it increases the risk of potential problems. And last but not least is code like this is hard to read/understand. I see your point, but you can’t expect every developer in your team to be as knowledgeable as you’re. Hope we’re on the same page here..

It turns out this assumption is false. The JVM really has some amazing abilities, which have been exposed in easy to use mocking APIs by certain open source tools.

Today it’s safe to say that, in the context of unit testing Java code, there is no such thing as “untestable code”.