Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <022101c65e3c$d88ac6a0$a95dbcd0@prasadsony>
From: "Fasih" <fasihullah.askiri@baypackets.com>
To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
References: <ce1f2ea80604111511o19df7c0ct5a0e00abd95c032e@mail.gmail.com>
Subject: Re: [SCXML] Document validation and testing (was: BUG: Inner States
 with no InitialState)
Date: Wed, 12 Apr 2006 09:24:41 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit

<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" <rahul.akolkar@gmail.com>
To: "Jakarta Commons Users List" <commons-user@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 <fasihullah.askiri@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