Thank you for the reply, James. Some responses will be inline,
followed by a conclusion after the main body.
On Aug 6, 4:03 pm, "James Mead" <jamesmea...@gmail.com
> Here are my responses to a subsequent comment from the same bug report
> Comment By: Yossef Mendelssohn (ymendel)
> > Date: 2008-08-06 00:17
> > Message:
> > I'd like to add my vote to this issue. I'm glad that the state machine
> > feature makes what I want to test possible with a setup method (or more
> > precisely, a before block, since I like RSpec -- and I think Mocha is better
> > than the built-in RSpec mocking), but it's kind of a pain and not entirely
> > nice to work with or look at.
> I'm glad that you think Mocha is better than the built-in RSpec mocking. Is
> there a way we could make using the state machine less of a pain? e.g. a
> helper method...?
> I understand that you prefer it to work a specific way, that you follow Jay
> > Fields's examples of duplicating code in your tests. What I'm not
> > understanding is
> > 1. Why it's not possible to write Mocha so that it can be used in a way
> > others expect as well as your preferred style.
> As you've already pointed out, it's not that it can't be used the way you
> want, it's just that it is a bit more awkward. You could suggest a patch to
> provide the alternative behaviour as a configurable option.
My main point was not that my workflow was not supported, since it
obviously is. The state-machine approach allows my needs to be met,
but in an awkward and involved way. You mention possibly using a
helper method to make this less of a pain, but I don't see what that
would do to alleviate the problem. It'll still mean I need to set up
an object to hold state and attach the stubs and expectations to the
different states. Hiding that behind a helper method still means I
have relatively the same amount of code in my tests that's not
actually directly related to testing (in my view).
> 2. Why Mocha needs to be brought into line with jMock v1, gotchas and all.
> As I explained to Rick Bradley: Although I admit that my response in the
> original bug report did not make this clear, the change was made to deal
> with some real problems & inconsistencies I was seeing. The change was not
> just made to bring Mocha "into line" with jMock. It was more that using a
> "mock method dispatch" mechanism like jMock's solved the problems I was
This was obviously a misunderstanding, then. I would be interested in
knowing what problems you were seeing that necessitated the change,
and I can do some digging to get a better understanding of the history
> 3. Dude, I don't know what to say. I'm not a fan of Java. At all.
> > Especially Java files that have .rb extensions.
> Thanks for such an insightful final comment.
Okay, I deserved that. I have personal issues, I'll admit. Being in
the Ruby world for as long as I have and enjoying it as much as I do,
and especially being in the position of a consultant/independent
contractor, I see far too much of what I deem is completely
unnecessary Ruby code. Or more to the point, completely unnecessary
code in files that purport to be Ruby, but are really born from
concepts that don't fit in with "the Ruby way".
> What I don't understand is that you seem to have assumed that I would not
> want to help you. You've not made any constructive suggestions or offered
> anything in the way of a patch. Can you explain why exactly I (or anyone
> else on this list) should bother giving up any of their time to help
This in part was due to misunderstanding your original response. At
the time I read it, it seemed very final about how Mocha would and
should work. Further interaction has proven that not to be the case.
Overall, I'm a big fan of Mocha. I continue to use it because it feels
the most natural and sensible of all the Ruby choices out there.
Having looked into the internals before, I realize there's a lot of
complexity that goes into a mocking framework, especially one as rich
and powerful as Mocha, and like any project with a large userbase,
there are conflicting desires and expectations.
Allowing expectations to override stubs would let both your* and my*
ways of testing work without any awkwardness. Any conversation about
this (whether or not either of us happens to be involved) seems to
come down to a disagreement about how tests should be written, with
neither party willing to back down. I can respect that others work or
think in different ways, and my general goal is to allow for different
workflows to coexist at the same relative comfort level. (Where
possible and where sensible, of course. This doesn't mean that they
should both be made difficult.)
(* For lack of better labels.)
I'll make some time to look into the test suite, hopefully sometime
soon, and see what would be involved in having my desired behavior be
optional (or dare I dream? default).