For me, dependency injection is not only a matter of testing, it's a question of clarity. Show me, right in the constructor, what your class depends on.

Dependency Injection is a way to achieve Inversion of Control - meaning the consuming modules aren't concerned with the implementation or instantiation of their dependencies. Dynamic languages have less of a need for Dependency Injection than statically typed languages, but things like instance lifecycle management and policy injection are still very much relevant for good modular design.

The point is, inverting control doesn't need a three letter acronym in Ruby, it is built into the language. You get those things automatically. No javascript programmer ever talked about singletons, and no Ruby programmer ever built an IoC container, because they are not needed. It's a mistake to think these are fundamental elements to programming, they are byproducts of particular languages.

Actually there is a framework: https://github.com/JoshCheek/deject

Have't tested it yet but it makes a lot of sense.

Redefining a class isn't dependency injection it's a hack to get the compiler to stop complaining. It works but it's very unclear to the person reading the program that a class your code depends on was actually redefined somewhere else.

For testing purposes placing this mock class somewhere at the start of your code is clear but only ever practical in that scenario.

I can also imagine that some programmers might not even think of the possibility that some code they depend on was overridden somewhere else.

In real maintainable code where you want to swap out behaviours it's nice if there was a special way of defining your dependencies. This is the same for all languages.

Deject offers a way so you don't have to fiddle with constructors but instead you have handles in your classes that you can override with different behavior if needed.

TL;DR: Yes, Ruby is powerful and you technically don't need IoC containers. But to make it maintainable for everyone it's a good idea to do so anyway.

Even if you don't give it a name, you are still doing it.

Yes, Like IntegerFloatAdding. If a programming language needs a pattern for adding an integer and a float, well, you have to call this pattern something. Until such a language is made, we can forget about "IntegerFloatAdding Pattern".

Yes, because it's a great idea to go globally changing things that are used across the virtual machine by the code of many more people than just you.

I must have blinked and missed whatever happened that made everyone think global variables are now all the rage.

...feel free to let me know why it's a good idea. Reflexive downvotes don't let me understand the voter's point of view.

That sounds like an awful idea.