I'm ok with an abstract Given, Event and Outcome for each mocking
framework (I mean, how many do we want to support?).
Each mocking framework has its own dialect and quirks, so I don't see a
useful abstraction that would give us much. We would still need several
interfaces, an adapter for each mocking framework into the mocking
parts, the syntax sugar parts and the constraint/matcher/etc parts, and
probably some other stuff.
Worse yet, if we abstract to the lowest common denominator, those
(majority) of us who are still in java 1.4 land will end up with ugly
casts all over the place, reducing readability even further.
In particular, until we have static imports, the syntax sugar has to
live in superclasses. I toyed with the idea of Return.value(sheep)
rather than returnValue(sheep) a while back, but things like constraints
just get ugly if you try to either use statics or compose them, and you
still end up in casting hell:
Ensure.that(sheep,
(Constraint)c.isA(Sheep.class).and((Constraint)c.not((Constraint)c.isWorried));
// eww
ensureThat(sheep, isA(Sheep.class).and(not(isWorried)); // better
Cheers,
Dan
Mauro Talevi wrote:
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
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
