Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

There was a problem

You must be a member of this account.

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

#13

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

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

State: new
Milestone: none
Assigned to: James Mead James Mead

Activity

  1. James Mead
    James Mead
    • 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.

    January 4th, 2009 @ 06:31 PM

  2. James Mead
    James Mead

    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')
      end
    

    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))
      end
    

    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.

    January 29th, 2009 @ 01:13 PM

  3. John Hume
    John Hume

    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
      end
      def method_missing meth, *args
        DeepStub.new("#{@name}.#{meth}")
      end
    end
    
    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)
      end
    end
    

    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.

    January 30th, 2009 @ 01:23 PM

  4. James Mead
    James Mead
    • Assigned user set to James Mead

    December 14th, 2009 @ 01:11 PM

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.