> My initial thought was that if you can construct an object so easily then why aren't you using it?

I often find it useful to use test doubles in place of easily constructable objects when those objects cause far-distant side effects (e.g. talking to a DB or external API), and I'm more interested in the communication patterns of the object's interface than in the side effects it causes.

I think there's a difference between how you conceived of and used rspec-fire and how I tend use it: you've talked about `unit_spec_helper.rb` and `spec_helper.rb`, where `spec_helper.rb` loads the entire app...but in my recent projects (which have _not_ been rails) I don't have any `spec_helper` file that loads everything: rather each implementation file is responsible for requiring it's direct dependencies.  This makes it trivial to have one-off rake tasks, background processes that load just what they need to work, w/o pulling in tons of bloat.  As a result, my isolated unit specs often are running with the object-under-test's dependencies loaded (since the object-under-test's implementation file required them).

Anyhow, let's plan to look more into this in another PR.