Floehopper mocha

Comments and changes to this ticket

• 

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

• You flagged this item as spam.
  

  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
    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.

• 

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

  • Assigned user set to “James Mead”

  I believe this commit [1] from jwilger is relevant.

  [1] http://github.com/jwilger/mocha/commit/c8a1160b903a0bbe854d236972c9...