[mocha-developer] Bug #17118 - expectations should take precedence over stubs
jamesmead44 at gmail.com
Sun Jan 20 12:11:04 EST 2008
I wanted to draw attention to this bug report [A] which highlights a change
that was made between Mocha 0.4 and 0.5.
It may have lead to tests which pass unexpectedly. Does my explanation
(below) make sense to people?
It feels like we should at least add some warnings to the documentation.
You are correct that this behaviour did change between Mocha v0.4.0 and
> v0.5.0 (in revision 115).
> The idea of this change was to bring Mocha into line with jMock v1  so
> that it stops matching expectations when the maximum number of expected
> invocations is reached. You are suffering from "gotcha" number 2 in that
> jMock reference: "if you create a stub and then an expectation for the same
> method, the expectation will match, and when it stops matching the stub will
> be used instead, possibly masking test failures". In your example, the
> "never" expectation will never match because it has already reached its
> maximum number of expected invocations, but Mocha will then find the stub
> which does match.
> Personally I prefer not to use setup methods, I prefer to make tests as
> self-contained as possible . I find this makes tests more maintainable
> (albeit at the expense of some duplication). So in this case I would prefer
> to *explicitly* put the stub expectation in every test that needed it. If
> setting up the stub expectation was complex or multiple stub expectations
> were needed I would extract that into a descriptive method and call it
> explicitly from each test that needed it.
> If you don't like this approach, you do have another alternative. Using
> "edge" Mocha (i.e. revision 233 or later), you should be able to use the
> state-machine feature to achieve your goal . This should be released as a
> gem soon.
> Thanks, James.
>  "Stubs, Expectations and the Dispatch of Mocked Methods"
>  "Testing: Inline Setup"
>  OverrideExpectationsFromSetUpAcceptanceTest
More information about the mocha-developer