I’m very interested in the status of a port of any_instance from Mocha
to RSpec.
In particular I have a spec suite that I wrote using RSpec but with
Mocha that depends heavily on any_instance. This is because it stubs
out one or two methods from an underlying API. In attempting to
convert the suite to RSpec mocks (because that’s what we’re using for
the rest of the project) I had to give up. Attempting to replace
objects by stubbing :new and returning mocks felt like a huge amount
of busy work compared to one-line with any_instance.
I noticed that Brian T. appears to have an implementation of
any_instance here:
which I tried, without success, to make work in my own version of
rspec (1.1.4). I was able to call any_instance but it didn’t seem to
be having an effect. I emailed Brian but I think he was at rails conf
so I guess he may be fighting a backlog of work/email.
Is there any likelyhood of any_instance making it into RSpec proper?
If not, has anyone else had any luck implementing it?
objects by stubbing :new and returning mocks felt like a huge amount
so I guess he may be fighting a backlog of work/email.
Is there any likelyhood of any_instance making it into RSpec proper?
If not, has anyone else had any luck implementing it?
There was an implementation of it that didn’t quite work for me in
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
.
Until such a patch comes my way, you can re-apply the existing patch
(probably have to use git-format patch and tweak some things - any git-
pros got advice on the best way to do that?) and it should work for
most cases for you.
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.
I tried searching the archives of this list but couldn’t find an
article where you (or anyone else) expands on this view about
any_instance.
And thanks for the pointer, I guess I will try and assemble the patch
and see if I can make it work.
described in Lighthouse - Beautifully Simple Issue Tracking.
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.
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.
This isn’t really a framework issue - it’s about TDD. Remember that
BDD started off as another way of framing TDD - it’s roots are still
in TDD.
As you’ve read before, TDD is a design practice, not a testing
practice. There is a testing benefit we get out of it, but the great
benefit of writing tests first is that you start off thinking from a
client’s perspective. This and the fact that you’re adding small bits
at a time, doing the simplest thing that could possibly work,
generally leads to more highly decoupled nuggets of code than back-
filling tests.
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.
any_instance is a global concept. Any time you’re doing something
global in an executable example you’re making it harder for yourself
to understand failures later.
I guess that it’s a bit more harmless with stubs, so, as I said, I’m
still open to adding a patch. I’m just not going to make it myself as
it’s low priority for me.
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 guess that’s how I see this. My code, that I am writing specs for,
depends upon a lower-level library that does not expose the details of
it’s implementation to it’s clients.
The use of any_instance allows me to test my code simply. Without it I
seem to be forced to build complex arrangements of mocks to,
essentially, emulate the behaviour of the underlying library. This
feels like busy work.
Whilst it would be possible to re-write the underlying library I do
not feel that’s a worthwhile investment of my time right now.
Especially not when I have a spec suite that already works but for the
lack of any_instance.
I’m all for encouraging good practice and wrapping any_instance in the
shame of your peers. But I’m also all for being pragmatic. Does your
patch work? I wasn’t clear whether David was saying that it doesn’t.
Regards,
Matt.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.