def mock_constraint
eq(self)
end

No need for respond_to?, no need for explicit class checking. The only concern is to make the mock_constraint command suitably unique to avoid name clashes.

How can the mock tell if an argument is a constraint or a normal object? It can’t without checking it’s class hierarchy or callnig respond_to? on it.

Looking at the class hierarchy is bogus in a dynamically typed language: the class hierarchy defines how the object is implemented and has no relation to its type. The type is defined solely by how the object responds to messages. So, it’s perfectly valid to define a constraint object by writing an object that has matches? and describe_to methods (or whatever they’d be in Ruby).

Using respond_to is equally bogus. I might use the method names matches? and describe_to? in other, unrelated, classes and want to set up expectations in which those objects are expected arguments. If the mock looked at the methods, it would incorrectly think that they were constraints, when they should instead be wrapped by constraints.

You may think that this is a bit academic, but I’ve been bitten by both problems when using Ruby libraries in real projects.

In a dynamically typed language you sometimes have to be more explicit about what you are passing around than you would in a statically typed language. That’s not a bad thing; it makes the code easier to read.

expect {mock.do_something(10)}
expect {mock.do_something_else(10), 42}

expect 3..4 {mock.do_something(10)}

mock = Mock.new “exampleMock”

expect 1 { mock.do_something(eq(10), !null) }
expect 3..4 { mock.something_else(eq(“hello”) }

... etc. etc…

I’ll discuss how to do this on Saturday if you want.

Secondly I agree you don’t need a proxy method to use method missing – the mock and the proxy can be the same thing. I was showing the .proxy call by way of showing a gradual move from JMock syntax/construct, to a more Ruby way of looking at it.

I have a problem with how messy Ruby syntax can end up looking, so seeing things like double underscores kind of makes me want to vomit. Sure, one you understand it it’s easy to read, but before then it’s a further barrier to entry (with lack of tool support, there are already enough of those).

MockIt is not readable to me at all, certainly not compared to JMock. Remember that the original idea was that JMock should read like a proper sentence but the Java syntax got in the way – with Ruby needing less in the way of brackets I think there is a chance of making the expectations more readable, not less.

I do agree about once() though – I’ve never found a need to use twice()!

Further, Ruby’s method_missing wouldn’t require you to have a proxy method on the mock to get the mocked instance. It can be the same object, thereby vastly improving its ease of use.

This would require that the mock’s “setup” methods don’t clash with the mocked methods. This can be achieved with a naming convention, like prefixing “setup” methods with ’__’.

This is the approach used in MockIt, a very small, but powerful mock library written by Jon Tirsen. You can find it here:

http://svn.damagecontrol.codehaus.org/trunk/rscm/test/rscm/mockit.rb
http://svn.damagecontrol.codehaus.org/trunk/rscm/test/rscm/mockit_test.rb

This mock implementation also hooks into Test::Unit’s teardown in a similar way to JMock, so that mock.verify is not needed. This requires you to use include the MockIt module (mixin) in your test and use the new_mock method to create a mock. Example:

http://svn.damagecontrol.codehaus.org/trunk/damagecontrol/test/damagecontrol/project_test.rb?rev=1458&view=auto

MockIt doesn’t have the JMock feel that would allow you to use structures like once(), but its usage of blocks for constraints makes it very rubyish. Example:

foo = new_mock
foo.__expects(:bar).do |param_1, param_2|

assert_equal(“hi”, param_1)
assert_equal(“there”, param_1)
“yo”
end
assert_equal(“yo”, foo.bar(“hi”, “there”))

This works really well for me. Imagine that we add support for JMock style invocation counts and possibly shorthand parameter constraints and invocation results such as:

foo = new_mock
foo.__expects(once(:bar)).with(eq(“hi”), eq(“there”)).will(return_value(“bar”))
assert_equal(“yo”, foo.bar(“hi”, “there”))

I’m not sure it would add that much to the readability. You get very far with blocks in Ruby and MockIt. I admit adding support for invocation counts such as once() could be implemented w/o sacrificing readability, but I rarely use other count qualifiers than once() anyway.

WDYT?

Much of the design behind JMock was there not only to make the expectations readable – which your code certainly is – but also to help the IDE create expectations using autocompletion (something that us Ruby programmers won’t be having for a while I think).

mock_obj = Mock.new(ClassToMock)
mock_obj.expects(

:do_stuff,
:with => [arg1, arg2],
:returns => someReturn
)

Kinda looks more like Ruby to me, but may go against some other JMock design principle I’m not aware of. What do you think?