[SCXML] Document validation and testing (was: BUG: Inner States with no InitialState)

[Rahul Akolkar <ra...@gmail.com>]

On 4/10/06, Fasih <fa...@baypackets.com> 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?
<snip/>

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="event.foo.bar"
 cond="_eventdata.foo eq 'foovalue'"
 target="bar"/>

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

 * An event with name "event.foo.bar" 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
benefit.

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 ;-)

-Rahul


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

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [SCXML] Document validation and testing (was: BUG: Inner States with no InitialState)

[Rahul Akolkar <ra...@gmail.com>]

On 4/12/06, Fasih <fa...@baypackets.com> wrote:
> <quote>
> 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 ...
> </quote>
> There is more than meets the eye. Lets say, on connection.alerting I call a
> ccxml:accept, that's it. How do I proceed further, given that the custom
> action can expect something in the payload. I guess, what we want to do is
> not a model validation but a compilation. IMO compilation should be the
> first step.
> This is what I see compilation as.
> 1. Validate against DTD [Already in place]
> 2. Generate classes for events rather than allowing strings to be entered.
> Something like an abstract class Event {} And instead of saying new
> TriggerEvent
> we do a exec.fire(new ConnectionConnectedEvent()). This should help
> eliminate the common typos. Having an interface would be even better as it
> will ensure that we dont make a mistake like ConnectinConnectedEvent also
> and not to use it.
> 3. Generate warning when for an event when there is a cond like "a eq b" and
> not "! a eq b"
>
> More ideas can be put in....
>
> Comments!!
<snip/>

Personally, I didn't understand the value of (2) very well and I'm not
very keen on (3) since I see no need for there to be any kind of
absolute expression closure for conditions on transitions for any
event. But (3) may be useful in certain scenarios, possibly yours ;-)

In any case, this discussion is somewhat of a bottomless pit -- and I
don't mean that in any negative sense, I find this interesting -- but
I suggest we stop here in the interest of others on this mailing list
who may not find this very relevant. To match that statement, I also
think the next thing one of us should do on this particular topic is
to post a concrete proposal or some code to convey our thoughts
better. Ofcourse, its generally a good idea to post proposals *before*
spending too much cycles, to gauge community interest. Finally, any
extensive "toolkit" would be beyond the scope of Commons SCXML.

-Rahul


>
> +Fasih
<snap/>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [SCXML] Document validation and testing (was: BUG: Inner States with no InitialState)

[Fasih <fa...@baypackets.com>]

<quote>
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 ...
</quote>
There is more than meets the eye. Lets say, on connection.alerting I call a 
ccxml:accept, that's it. How do I proceed further, given that the custom 
action can expect something in the payload. I guess, what we want to do is 
not a model validation but a compilation. IMO compilation should be the 
first step.
This is what I see compilation as.
1. Validate against DTD [Already in place]
2. Generate classes for events rather than allowing strings to be entered. 
Something like an abstract class Event {} And instead of saying new 
TriggerEvent
we do a exec.fire(new ConnectionConnectedEvent()). This should help 
eliminate the common typos. Having an interface would be even better as it 
will ensure that we dont make a mistake like ConnectinConnectedEvent also 
and not to use it.
3. Generate warning when for an event when there is a cond like "a eq b" and 
not "! a eq b"

More ideas can be put in....

Comments!!

+Fasih
----- Original Message ----- 
From: "Rahul Akolkar" <ra...@gmail.com>
To: "Jakarta Commons Users List" <co...@jakarta.apache.org>
Sent: Tuesday, April 11, 2006 5:11 PM
Subject: [SCXML] Document validation and testing (was: BUG: Inner States 
with no InitialState)


On 4/10/06, Fasih <fa...@baypackets.com> 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?
<snip/>

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="event.foo.bar"
 cond="_eventdata.foo eq 'foovalue'"
 target="bar"/>

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

 * An event with name "event.foo.bar" 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
benefit.

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 ;-)

-Rahul


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

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org