For simple scenarios DI is obviously an overkill, but as soon as you're dealing with nested dependencies, you'd end up with either:

* monstrously big constructors (for carrying transitive dependencies)

* lots of @VisibleForTesting code to handle manually injecting various dependencies only for the sake of testing (poor man's DI and generally bad practice)

* a lot of factories (service locator or poor man's DI, essentially)

* code that's hard to unit test due to dependencies being hardcoded.

In other words, you'll either reinvent DI poorly, or give up on testability.

Constructors in the middle of your code make it harder to substitute mock objects for testing purposes.

The problem is not the testing. The problem is that if you have classes that depend on other classes that depend on other classes that depend on specific configuration.

Then you have a mess without DI.