Perhaps this wasn’t clear enough, but I was making an explicit distinction between dependency injection and dependency injection frameworks.

Dependency injection makes code easier to test, and I’m a big fan of dependency injection.

What I’m opposed to is the frameworks that automate (and often hide) the construction of the dependencies.

As someone else said in this thread “explicit is better than implicit”.

DI frameworks always make me deal with way more of the system than I want to.

I want to just be able to 'new' any class in the system, and start playing with it under test.

When I try to test a Parser class under a framework DI, it ends up instantiating the most fiddly bits of unrelated crap. I get null pointers in the database config, which had nothing to do with what I wanted.

It can be controlled, by adding even more annotations and mocking frameworks. But I'd rather take out annotations rather than put them in.

But you don’t have to do it that way? You can still manually instantiate your Parser in your test and have DI