I started down this path and then backed it out.
Thing is, you need the syntactic sugar in the class so you can
returnValue(sheep). This will necessarily vary from framework to
framework (the type of returnValue(Object) in jmock is different from
the equivalent in minimock, because it's a parameter object to a jmock
class).
The /right/ thing to do is for scenario classes not to have any mocking
stuff in themselves, but to implement UsingMocks. Then the hasMocks()
and verifyMocks() methods just delegate down to the steps (ie. the
givens, events and outcomes).
You'll see this in MultiStepScenarioBehaviour. MultiStepScenario doesn't
extend anything - it just implements Scenario, which itself extends
UsingMocks.
That way, your steps can be independently mocky - you can have a Given
using minimock playing nice with an Outcome using jmock, say, because
everything is a ScenarioComponent, which extends UsingMocks. Smart girl,
that Liz.
So really, we're already good :)
Mauro Talevi wrote:
Hi,
I was looking into making the mocking framework used by scenarios
injectable.
I would:
- pull up to UsingMocks interface methods now found in UsingMiniMock,
UsingJMock ... eg
Mock mock(Class type);
Mock mock(Class type, String name);
Object stub(Class type);
Object stub(Class type, String name);
All mocking frameworks must be able to honour this interface.
- introduce a decorator impl of UsingMocks that delegates to specific
implementations - MiniMock, JMock, etc ... - as a convenience base to
subclass which is itself independent of the mocking framework.
While on the subject, I would also:
- move Ensure and UsingMocks interfaces to core.mock package - for
consistency with other packages.
- remove deprecated Verify
Finally
- any reason why we are using Block interface instead of standard JDK
Runnable?
Comments? Objections?
Cheers
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
