Floehopper

  wotsit = Mocha.new
  wotsit.expects(:thingummy).with(5).returns(10)
  doobrey = Doobrey.new(wotsit)
  doobrey.hoojamaflip
  wotsit.verify

  wotsit = mock()
  wotsit.expects(:thingummy).with(5).returns(10)
  doobrey = Doobrey.new(wotsit)
  doobrey.hoojamaflip
  # no need to verify

  wotsit = Mocha.new
  wotsit.expects(:thingummy).returns(10)
  wotsit.expects(:summat).returns(25)

  wotsit = mock(:thingummy => 5, :summat => 25)

  wotsit = Mocha.new
  wotsit.stubs(:thingummy).returns(10)
  wotsit.stubs(:summat).returns(25)

  wotsit = stub(:thingummy => 5, :summat => 25)

Posted in mocha_release | Tags mocha, mock, mocking, rails, ruby, stub, stubba, stubbing, test, testing | 4 comments

Comments

1. nukeedit
   Mario Aquino said about 1 hour later:
   

   I like that you don’t have to call verify but the shortcuts leave the code less readable (for my eyes) regarding what the intent of the test is. Mocha is awesome!

2. nukeedit
   James Mead said about 5 hours later:
   

   Thanks for the feedback, Mario – I’m glad you like Mocha. I agree that in some ways the shortcuts are less readable, but I think they can improve the overall readability of a test by reducing the clutter. In any case the shortcuts are optional, so go ahead and write the expectations out in full if you prefer it. Personally I think the shortcuts are most useful for stubs.

3. nukeedit
   Dylan said 3 days later:
   

   Thanks for writing Mocha – gives those of use who are still using test_unit instead of rspec some good mocking functionality.

   While working with it I had a few problems with dynamic method calling. Basically, I test respond to and if it is successful I call the method using mock.method(name).call(*args). This was failing, since the method did not actually exist. My hackish solution is below.

   class Mocha::Mock
     def method(method_name)
       MockCall.new(self, method_name)
     end
   end
   
   class MockCall
     def initialize(mock_object, method_name)
       @mock = mock_object
       @method_name = method_name
     end
   
     def call(*args)
       eval %{
         @mock.#{@method_name}(*args)
       }
     end
   end

   Of course, if you are setting expectations for the call ‘method’ this code would interfere with that. Dynamic programming makes mocking a whole new bag of fun.

   Also, I have to do some hackish things because defining new methods (through the singleton class) on a mock interferes with the expectations.

4. nukeedit
   James said 3 days later:
   

   Dylan: I’m not sure I completely understand the problem you’re trying to solve. Can you give a simple example of how you would use this new functionality?

   That said, I think you have correctly pointed out a flaw in Mocha – a mock will return false when calling respond_to? for an expected/stubbed method. So the following test currently fails…

     def test_should_respond_to_expected_method
       mock = mock()
       mock.stubs(:expected_method)
       assert mock.respond_to?(:expected_method)
     end

   ... I will try and fix this asap. If this test passes, would your problem be solved?

RSS feed for this post

Comments are disabled