#13 new
James Mead

[#22564] Allow default return value to be specified for stub_everything

Reported by James Mead | January 1st, 2009 @ 07:07 PM

Date: 2008-10-26 19:15 Opener: James Mead

John Wilger says:-

Using stub_everything as opposed to just stub can alleviate that to some degree, however the one thing I don't like about Mocha is stub_everything returns nil for all calls. If it instead returned self by default, then it would work better for this kind of situation. (If anyone knows that there /is/ a way to cause Mocha to behave this way, please speak up!)

James Mead comments:-

I'm not convinced always returning "self" is the right thing to do, but having control of the default return value seems like a sensible request.

Cheers, James. http://blog.floehopper.org

Comments and changes to this ticket

  • James Mead

    James Mead January 4th, 2009 @ 06:31 PM

    • Tag set to feature-request

    John Hume made a useful suggestion in http://rubyforge.org/pipermail/m...

    His idea is to have the option to return a "stub_everything" which has some knowledge of how/where it got created.

  • James Mead

    James Mead January 29th, 2009 @ 01:13 PM

    I'm wondering whether it would be better to introduce the idea of Method Matchers as a more flexible alternative to stub_everything. So stub_everything would become...

      def test_me
        stub = stub('stub-name', anything => 'default-return-value')

    One reason I like this is because it simplifies the Mocha API (i.e. stub_everything is could be deprecated).

    John Hume's suggestion could then be implemented like this for as many 'levels' as you need...

      def test_me
        stub = stub('level-1', anything => stub('level-2', anything => nil))

    I'm inclined to think that John Wilger's original suggestion could be added to a Mocha extension for working with legacy code. This extension could also include the whole proxy/interception malarky (as seen in RR).

    However, the idea of Method Matchers might present difficulties in stubbing methods on concrete classes i.e. we'd have to iterate through all possible methods and see which ones matched so that they could be hidden and invocations intercepted successfully. Maybe this isn't too hard. In any case, to start with we could disallow Method Matchers for concrete class stubs.

  • John Hume

    John Hume January 30th, 2009 @ 01:23 PM

    The method matcher idea is interesting. I'm imagining an API that lets you chain selectors together, though I'm not sure it would be sane to use something like that (nor that it would be any more readable than the existing non-hash approach).

    As far as the goal of the ticket, the one thing you lose with this generic method matcher-based approach

    stub('level-1', anything => stub('level-2', anything => nil))

    is visibility into what call or series of calls got you to a given nested stub. It would be pretty easy to do that in a purpose-built class sort of like this.

    require 'test/unit'
    class DeepStub
      def initialize name
        @name = name
      def method_missing meth, *args
    class FooTest < Test::Unit::TestCase
      def test_deep_stub_everything_builds_names_from_method_chains
        jimmy = DeepStub.new('jimmy')
        assert_equal "jimmy.foo.bar", jimmy.foo.bar.instance_variable_get(:@name)

    On the other hand, if the request is really just to be able to specify a default value for a stub_everything, the "anything" method matcher satisfies that nicely.

    I'll just restate for the record that while I find my DeepStub fun to think about implementing, I don't think I want that feature in mocha or in the tests of any codebase I have to work on.

  • James Mead

    James Mead December 14th, 2009 @ 01:11 PM

    • Assigned user set to “James Mead”

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

A mocking & stubbing library for Ruby.

* <a href="http://github.com/floehopper/mocha">GitHub repository</a>
* <a href="http://mocha.rubyforge.org">Documentation</a>
* <a href="http://groups.google.com/group/mocha-developer">Mailing List</a>

People watching this ticket