Dan North wrote:
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).
That's true but these methods could live in the decorator and return the lowest common denominator
Object, which can be castable by the subclass.
Or better, live in a separate class so we break the inheritance pattern.
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.
The interface approach is fine, no issues there.
But the question then becomes - what you do mean by allowing the injection of mock framework in the
implementation of the interfaces?
Seems that what you are saying here is that we should have an impl for each mock framework and for
each scenario component - ie GivenUsingMiniMock, GivenUsingJMock, OutcomeUsingMiniMock,
OutcomeUsingJMock, etc ...
So really, we're already good :)
I'm probably missing something between the lines here :-)
Cheers
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
