[stormbrew]

I think that isolation testing files is considerably harder than isolation testing classes. You can't force isolation of one by using isolation of the other.

For requires going stale, I mean when a file originally depends on something but no longer does. The require is likely to linger, especially if the dependency is removed without knowing that it was the entirety or the last of the dependency. This file now has stale dependencies.

Then something requiring that file will have that dependency in place and possibly use it without requiring it because of that. This file now has incorrect dependencies.

Expand the above across a more complex project and it becomes virtually impossible to verify the correctness of your requires, so you probably just stop trying and require things as needed, which makes it worse.

When you finally discover it your changes (in your version control) become less isolated as random requires start popping in and out.

This is not a new or unique problem to Ruby, obviously. C/C++ headers have a very similar problem.

[anti-pattern]

Ah, well, nothing is foolproof. Yes, if you don't update your dependency list when dependencies are removed, they might get stale. But I keep up on that stuff and haven't ran into that problem yet. Even if I did, I'd rather have that problem than an app where all the dependencies are global.

[stormbrew]

Sure. I guess what I'm trying to get at here is that, while I'm not fond of the Everything Is Magic approach rails often takes, I actually think this is one case where it was an entirely pragmatic effort to work around a poorly developed area of the ruby language when a program gets large (in terms of files, lines, or both). And Bundler.require is an evolution of that practice.