Comments on: From Mocks to Expando

By: Ben Butler-Cole

Ben Butler-Cole — Wed, 13 Dec 2006 22:17:49 +0000

Hi George

Expando appears to be a great way of knocking up a stub, but a poor substitute for a mock. The problem is that there is no point in the test where you clearly say “the ForwardResponder should forward the response using the dispatcher”.

The alternative with mocks (JMock here) reads much better to me:

dispatcher.expects(once())
.method(“forward”)
.with(eq(request), eq(response));

Rather than splitting the statement across a local variable definition, an assignment and an assertion, it’s all there in a declarative and fairly readable (modulo Java syntax) way.

I agree with you that mocks returning mocks leave a nasty taste in the mouth. Here I would use a stub (by all means a glossy Expando stub if you have such a thing to hand) for the request which returns the dispatcher mock.

And I would leave assertions about the location passed to the request for another test. Indeed I would extend the “one assert per test” guideline to “one mock per test”.

Ben

By: Jesse O'Neill-Oine

Jesse O'Neill-Oine — Mon, 11 Dec 2006 06:06:02 +0000

This solution just gives you that “yeah, that’s how that should work” feeling. This same pattern would work great in JavaScript too, which is nice in a Web 2.1415 world. Stub on steroids seems like the perfect description.

Thanks!

By: George Malamidis

George Malamidis — Fri, 08 Dec 2006 15:09:00 +0000

Geert,

Yes, you’re right. I’ve ammended the test to reflect your and Nat’s observation. Thanks for pointing this out.

By: Geert Baeyaert

Geert Baeyaert — Fri, 08 Dec 2006 13:56:05 +0000

This is puzzling.

As far as I understand, if getRequestDispatcher is not called, the code in the closure won’t be executed, including any asserts that might be there.

What am I not seeing?

By: Jeff Santini

Jeff Santini — Fri, 08 Dec 2006 10:40:35 +0000

Actually the paper is not that short, sections 4 “Mock Objects in Practice” and 5 “Misconceptions about Mocks” are the bits more related to how Mocks can go wrong and what is the pro-Mock answer to these problems.

By: Jeff Santini

Jeff Santini — Fri, 08 Dec 2006 10:35:53 +0000

Hi George,

I am very much in favor of your “crusade” against the bad things people can do with mock libraries. In relation to Nat’s comment above and your reply that your expando object is a mock, would I be right in saying people who compain about mocks(myself included) do so pretty much because of their misuse, not because they serve no purpose?

The paper at http://www.jmock.org/oopsla2004.pdf lays out the case for mocks. Is there anything in there to disagree with?

By: James

James — Fri, 08 Dec 2006 09:28:25 +0000

Seems like my post has been truncated.

Here’s a link to the example Ruby test using Mocha.

http://pastie.caboo.se/26540

By: George Malamidis

George Malamidis — Fri, 08 Dec 2006 09:21:01 +0000

~~Geert,~~ ~~assert "/location" == location~~ ~~If getRequestDispatcher() is not called, this assertion will fail.~~ ~~Same goes for the assertions relevant to the forward() method~~

By: James

James — Fri, 08 Dec 2006 09:19:01 +0000

I think your comparison is a little unfair. It would be better if you wrote out the code for the version of the test using mocks. I’ve had a quick attempt at writing an equivalent test in Ruby using the Mocha mocking library and I would say it compares very favourably with your Expando based one…

require ‘mocha’
require ‘test/unit’

class ForwardResponderTest

By: Geert Baeyaert

Geert Baeyaert — Fri, 08 Dec 2006 08:55:43 +0000

Yes, but as Nat said, it doesn’t tell you whether any of the expected calls was actually called.

Doesn’t that worry you?