On Mon, Sep 15, 2008 at 5:09 AM, Joseph Wilk <[EMAIL PROTECTED]> 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" > #Given > setup some mock/stubs > > #When > perform action > > #Then > Check whether the behaviour was as expected. > end > --- > > 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. > some.action(x) > > 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: http://dannorth.net/2008/09/the-end-of-endotesting. > ((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) > http://rspec.lighthouseapp.com/projects/5645/tickets/527-adding-spy-to-rspecs-mocking-framework Thanks for getting this conversation going. Cheers, David > -- > Joseph Wilk > http://www.joesniff.co.uk _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
