-----Dan North <[EMAIL PROTECTED]> wrote: -----

>I'd rather keep minimock, um, mini. Usually if you want to mock a
>class, it means there's an abstraction you're missing. What 
>role is the class playing that needs mocking? And is there an interface
>that you don't have yet that would represent that role?

So, the context for this is:

My game gets movement requests, via various queues. Depending on whether it's running or not, it tells the glyph to move itself. (The alternative requires feature envy.)

Most of the game behaviour definitions do the right thing: they add a listener to the glyph, tell the game to move it and check that it's moved to the right place. However, I really want to add behaviour to check that the game does in fact delegate all methods correctly to the glyph; using a mock, because the test reads more cleanly.

Many of the projects I've worked on have required this at some stage or another, often as an interim measure while refactoring was going on. Dan and I have now a long IM conversation in which he attempted to persuade me that my approach could be improved; my argument is that he'd have to have this conversation with half the users of JBehave in order to get them to use Minimock instead of JMock. The JMock devs tried this already and the cglib extensions were born as a result. Now, we could argue that anyone who's dumb enough to mock concrete classes should just use JMock, but right now that would include me.

And Minimock rocks enough that I want to carry on using it.

So, I agree that it's not the right thing to do.
I agree that I should probably refactor my code to do the right thing.
But I'm going to do the wrong/pragmatic thing anyway, and I'm going to get JBehave to help me. :)

Cheers,
Liz.

--
Elizabeth Keogh
[EMAIL PROTECTED]
http://www.livejournal.com/users/sirenian

--------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email

Reply via email to