I have to say that the entire notion of Dependency Injection is overrated.
You are not injecting dependencies - the dependency is explicity stated in all cases, whether injecting or not. For example, you will always declare a variable of the desired type, hence you are stating the dependency explicity, whether using DI or not.
The things you would like to be able to inject, but can't, are anything that involves more than instance - can you have multiple Orders - can't inject it. Can you have more than one Invoice - can't inject that.
Most (all) injection involves injecting singleton instances - i.e. classes which have only one instance ever and are injected wherever desired. These instances are all created at startup time and cached for the duration of your application run, increasing startup times, increasing memory usage, and forgoing GC for all injectables.
Also, as some have referred to above, injecting only creates the dependency - if you want to fill the dependency with a mocked object, you will need to have a completely different configuration available which provides the mock definition for every single instance of injection in your code. This means auto-wiring (which most injectors are using because it was the only way they got it to work) is not an option.
In all honesty, the easiest way to test a class is to ensure that all dependencies are created in a method that can be overridden. Then create a Test class derived from the actual class and override that method.
Then you instantiate the Test class and put it through its paces.
In code, this concept looks like this...
class SomeClass { ADependency aDependency; AnotherDependency anotherDependency; public void initializeDependencies() { aDependency = new ADependency(); anotherDependency = new AnotherDependency(); } } class TestSomeClass extends SomeClass { public void initializeDependencies() { aDependency = new ATestDependency(); anotherDependency = new AnotherTestDependency(); } } That is the exact equivalent of DI - with the only differences being that it is more concise, easier to code, easier to understand, faster, uses less memory, does not require an alternate configuration, does not require any frameworks, will never be the cause of 4 page (WTF!) stack traces that include exactly ZERO (0) classes which you wrote, and is completely obvious to everyone from beginner to Guru.
The only thing it requires is a little discipline in class design - Ohh crap, that's it, this will never work!
Actually, if you create a TestableObject interface, which defines a method initializeDependencies(), then you could implement that interface in any class you want to test. Even a dummy could figure out how to use that, I think.
If you did that, then at test time, you could inject instances of every class that implements that interface using a DI framework (grin)!