On 4/10/06, Fasih <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
