commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject [SCXML] Document validation and testing (was: BUG: Inner States with no InitialState)
Date Tue, 11 Apr 2006 22:11:56 GMT
On 4/10/06, Fasih <> wrote:
> I think that the validation will be quite some task. I started off thinking
> on how to go about it, the first problem is the PayLoad. I can generate
> events, but what payload to use! At least in my case, there is a heavy
> dependency on the payloads of the event. Any suggestions?

Incidently, there happened to be a thread on one of the other lists
(either struts or myfaces) that I only had a cursory glance at which
talked about tooling for expression languages (or the lack thereof).
Lets say we are given some "smarts" such that by introspecting this
transition element:

<transition event=""
 cond=" eq 'foovalue'"

we get informed that this transition will be followed if and only if:

 * An event with name "" is received
 * The payload has a readable property "foo"
 * The value of the payload's "foo" property is "foovalue"
 * The transition target "bar" exists

[Commons SCXML already verifies the fourth bit at document parsing time.]

Then, the validation and generation of test cases for path coverage
around this transition has become one step easier. However, as you'll
notice, this means that such support needs to be "layered"
appropriately, the EL used needs to be amicable to introspection so
the SCXML test tooling can be built on top of that, and so on ...

A more down to earth approach may be to begin with a simple generic
"SCXMLTestCase" that given a state machine, a list of events to be
fired (already populated with payload instances) in some order, and
the expected outcome at each step runs through that single execution
to validate the test. This should be trivial, the Commons SCXML test
cases pretty much do this. Further, small incremental conveniences can
be added, for example, a generic payload class that wires readable
properties via a CSV constructor argument can reduce the amount of
procedural code to write to come up with a test case. A lot of
introspection can be done on the Commons SCXML object model (barring
the EL bits) to figure out the topology of the state machine i.e. a
SCXML object exposes its child states, a State object exposes the
candidate outbound transitions and so on ... that can be used to our

Ofcourse, as we try things, more and better ideas will probably
surface. This is all quite "researchy" in my mind, which is one of the
reasons I find it interesting ;-)


> And yeah, If I do
> manage to get something out, would definitely share it with Commons.
> +Fasih

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message