Verifying Expectation halfway through the test

[farnoy]

Is there a way to check single Expectation before the end of a test?

Rspec-Mocks has following syntax

it "should increment the count" do
  expect { Counter.increment }.to change{Counter.count}.from(0).to(1)
end

and it got me thinking if it's possible to verify expectation and then replace it with another one (for example to test two functions in one test case).

[floehopper]

Hi Jakub. Interesting idea. However, I can't really see why it would be useful. Why wouldn't you just split the test into two tests with a different expectation in each? Do you have a concrete example where this idea would be useful? Thanks for your interest in Mocha. Cheers, JM.

[farnoy]

Hi, sometimes when I call two methods that call another one, I have to set the .times() for the expectation, and it's not specific as to which method calls the other one, for example

• a calls c once
• b calls c twice
• .expects(:c).times(3)

when a and b change, a can call c three times and b can never call c, so the behaviour is very different, but the test still passes.

I guess splitting the test is a good way to go, but I was just curious if there's a possibility in mocha right now for that.

[floehopper]

So if I understand you correctly, you're saying that given a class and test like this :-

class MyClass
  def initialize(collaborator)
    @collaborator = collaborator
  end

  def method_one
    1.times { @collaborator.foo }
  end

  def method_two
    2.times { @collaborator.foo }
  end

  def method_three
    method_one
    method_two
  end
end

require "test/unit"
require "mocha"

class MyClassTest < Test::Unit::TestCase
  def test_method_three
    collaborator = mock("collaborator")
    my_object = MyClass.new(collaborator)
    collaborator.expects(:foo).times(3)
    my_object.method_three
  end
end

I can change MyClass#method_one and #method_two as follows :-

def method_one
  2.times { @collaborator.foo }
end

def method_two
  1.times { @collaborator.foo }
end

And the test will still pass. Is that what you mean?

I think the way it currently works makes sense to me. The test only cares how many times collaborator#foo is called it does not care which method calls it. If #method_one and #method_two call #foo with different parameters, then you might need to be more specific with your expectations, i.e. use Mocha::Expectation#with to constrain the expected invocations of #foo.

If you care about how many times #method_one calls #foo then maybe you should have a test that only calls #method_one and then you can have an expectation for a specific number of invocations.

You might also want to look at the Mocha::StateMachine examples e.g. Mocha::Expectation#when, Mocha::Expectation#then. This might allow you to do something like what you are talking about.

So far I haven't been convinced to make any changes to Mocha. If you are happy with the above explanation, can you close this issue? Otherwise you need to try harder to convince me that Mocha is missing some important functionality!

[farnoy]

You did understand me correctly and both solutions that you've provided are great. I wasn't aware of the StateMachine implementation, I'll have to take a closer look at it. expect blocks really seem useless now.

Thanks for your time and a lengthy response