Dependency injection subjugates readability and simplicity of data flow for a narrowly defined notion of testability. Even in languages like Java, it's possible to substitute class definitions for mocked ones without having to thread a weird sort of test monad through code that otherwise serves a purpose.
I pretty fundamentally disagree with making production code more complex to make unit tests easier to write. Make the tests more complex instead and think about the natural units for testing. Maybe the natural unit for testing isn't exactly one class.
This is counter to the conclusion of the article: it's true one shouldn't force Java idioms on Ruby but also if the Java idiom doesn't translate well, maybe it's a bad programming idiom in general.
Fair, except that DI in Ruby is pretty dang simple.
def some_method(dependency = SomeClass.new)
dependency.do_something
end
I'd argue that injecting the dependency gives you even more expressiveness and improves readability since you now can name the dependency whatever you want (assuming you give your variables meaningful names and think it's a good thing).
I'm with you on everything you wrote there, except that I think DI has more applications than just unit testing. Inversion of control, whether via DI or otherwise, is potentially useful any time you need more than one variation of a part of your system and the ability to swap them around on the fly.
I pretty fundamentally disagree with making production code more complex to make unit tests easier to write. Make the tests more complex instead and think about the natural units for testing. Maybe the natural unit for testing isn't exactly one class.
This is counter to the conclusion of the article: it's true one shouldn't force Java idioms on Ruby but also if the Java idiom doesn't translate well, maybe it's a bad programming idiom in general.