[rspec-users] Adding Test Spy into Rspec mocking framework
dchelimsky at gmail.com
Mon Sep 15 08:18:57 EDT 2008
On Mon, Sep 15, 2008 at 5:09 AM, Joseph Wilk <lists at ruby-forum.com> wrote:
> Thanks to a pointer from lizkeogh.com site I've been discovering the joy
> of the Mockito (http://mockito.org/) mocking framework for Java. It
> verifies behaviour after the action. It struck me how this matched the
> format I use in my Ruby cucumber features. Within Rspec if we could use
> post behaviour verifications I could unify the format of my specs with
> my features. Specs could look like:
> it "should make verfication of behaviour after action"
> setup some mock/stubs
> perform action
> Check whether the behaviour was as expected.
> While we can do this with output checks in Rspec we cannot do such a
> thing with 'should_receive'.
> Having a consistent format for specs and stories sounds like a great
> idea to me.
> Also the separation of the verification from the Given set-up is nice.
> So I'm proposing the idea of adding 'should_have_received' and test_spy
> in Rspec:
> x = test_spy('like a mock but more into espionage')
> #Action which does not fail on unexpected method but just records calls.
> x.should_have_received(:method).and_returned_with('some string')
> What I'm still looking at is if the idea of post validation is possible
> in the Rspec framework mocking framework. I know RR
> (http://github.com/btakita/rr/tree/master) is looking at implementing
> the Spy pattern which will enable this sort of testing.
The main technical problem with this is that RSpec's mocks are
designed to fail fast, and that would have to be turned off for
objects intended to simply record calls. It might be that what you're
talking about should really be a completely separate implementation
which, I might add, would probably be quite trivial compared to the
complexities of failing fast in a variety of contexts.
> Do people think this would be a good addition to Rspec?
My initial reaction is "no" based on a couple of things:
1. Mocks are intended for the indirect discovery of new objects and
their behaviours while driving out their consumers with code examples.
If our stories start using them for this purpose, we're heading
towards what I view is too granular a view from the story level.
2. Mocks can get separated from the real implementations, meaning that
all the code examples can pass yet things can fall apart in production
if the mocks aren't maintained in alignment with the real
objects/methods. The risk of using mocks in code examples is
significantly mitigated with the use of scenarios as integration
tests. As soon as we start using mocks in stories as well, we're
reintroducing that risk and likely increasing it.
Now with all of that said, I think this is worth exploring. I'm just
not sure that exploration should occur in rspec proper. What I'd
encourage you to do is write either a standalone library with hooks
that you can exploit from rspec examples and/or rspec/cucumber
scenarios or write an extension library for rspec's mocking framework.
I'd also recommend that everyone interested in this thread read Dan's
article about endotesting/mockito:
> ((I'm really excited with the idea and I have started playing around
> with some code for a prototype. If its not for Rspec I can always look
> at it for RR.))
Doesn't RR already support test spy?
> I've added a issue in lighthouse (though its behaving very strangely at
> the moment not picking my ticket up in searches/tags)
Thanks for getting this conversation going.
> Joseph Wilk
More information about the rspec-users