Dan North wrote:
Hi gang.
Please read this all the way through - it probably affects _you_. :)
I reworked a lot of the scenario stuff over the last few days. Mostly it
comes down to this:
1. A MultiStepScenario is made up of a bunch of Steps, defined in an
assemble() method.
2. A Given, Event or Outcome is considered a step, and can be added in
any order.
2a. So is another Scenario (which is wrapped as a GivenScenario, as before).
3. Err, that's it.
Well ok, it's not /quite/ it. There are protected methods given(Given),
when(Event) and then(Outcome). Which means that one of Liz's more
complicated steppy scenarios now reads like this:
public class ThePlayerRotatesTheGlyphLeft extends MultiStepScenario {
public void assemble() {
given(new TheFirstGlyphIsDisplayedOnTheBoard());
when(new ThePlayerPressesLeftRotate());
then(new TheGlyphShouldTurnToOneQuarter());
when(new ThePlayerPressesLeftRotate());
then(new TheGlyphTurnsToTwoQuarters());
when(new ThePlayerPressesLeftRotate());
then(new TheGlyphTurnsToThreeQuarters());
when(new ThePlayerPressesLeftRotate());
then(new TheGlyphShouldBeCentredAtTheTopOfThePit());
}
}
which I hope you'll agree is quite readable, and very light on {curly
braces}.
Just to clarify - is the scope of assemble() to avoid big constructors
or is there another usecase for it?
Also there's a new interface called HasCleanUp which defines
cleanUp(World). If any of your steps implement this, they'll be called
in reverse order on the way out of the scenario.
The composite classes Givens, Events and Outcomes have all disappeared,
as have
ScenarioUsingMiniMock and any other Steppy stuff.
Yep - nice one, better without composites.
Enormous thanks to Liz for having put all the hooks in place to make the
Scenario rework possible - particularly ScenarioComponent and Step.
Also thanks to Joe for the Fermat-like comment about how much simpler
scenarios could be.
*TODO* (guess who hasn't put this in Jira yet?) in no particular order:
1. Remove Scenarios composite. It has feature envy of a Scenario and is
only used in one place anyway.
Done
2. Rename Constraint to Matcher everywhere, including variable names
(yawn!).
Not sure what you mean ... Constraint is JMock class.
3. Replace the AWT 1.1 code (ie. anything using EventQueue) in the Swing
harness with the equivalent Swing events. I'm pretty sure that's what's
causing the race conditions under various JDKs. Also, the Idler should
simply invokeAndWait on a NULL_RUNNABLE - it doesn't need any
synchronization magic.
4. Make the choice of mocking injected rather than inherited. Scenarios
should be able to use JMock or MiniMock.
+1
5. There's a bug in the new behaviour method runner. It doesn't create a
new class instance for each behaviour method that runs. Not sure why
yet, but I can prove it :)
6. Put all the above in Jira (actually /don't/ - instead keep your eye
out for exciting story-tracking news).
Do, don't, do, don't ... man, you're definitely in touch with your female side
today :-)
Cheers
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
