On Jun 4, 2008, at 9:40 AM, Matt Mower wrote:
Hi David.
On Wed, Jun 4, 2008 at 2:24 PM, David Chelimsky
<[EMAIL PROTECTED]> wrote:
There was an implementation of it that didn't quite work for me in
http://github.com/dchelimsky/rspec/commit/45a6837 so we reverted
it. I have
zero personal interest in this feature (use of which I find to be an
anti-pattern) but am open to applying a patch as long as it meets
criteria
described in http://rspec.lighthouseapp.com/projects/5645/tickets/28.
I've read the ticket, I was hoping it would explain why you feel
any_instance is an anti-pattern.
In my situation I am spec'ing a library that depends upon a
lower-level for network operations. I use any_instance at certain
points to simulate data coming from the network.
Trying to stub :new and return a mock was very problematic for me
because the object involved does some work with the data which my code
depends upon for it's own behaviour. Hence to test that I end up
having to do a lot of work in my mocks and it quickly becomes
cumbersome.
What I really wanted was the "genuine" object with some behaviour
changed which is what any_instance gives me.
Why can't you give public access to the object? You'd then be able to
stub it, just as with stub_all_instances.
There's a general idea with rspec (and one which probably isn't
present in other testing frameworks) that says that testing *should*
influence your design. I'm sure this is one of the reasons that David
considers it an "anti-pattern" - as it does not influence your design
in any way. In fact, I developed the the stub_any_instance patch
because I needed to test legacy code (legacy because it wasn't
designed well), and it was the only way to get to the object.
I'm sure David would have specific examples, and I'd be curious to see
them.
Scott
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
