On Sun, Aug 1, 2010 at 3:37 PM, Jacob Beard <jbea...@cs.mcgill.ca> wrote: > Hi, > > I'm currently trying to determine the best way to test the external > communications module in scxml-js. Right now, dependency injection is used > to pass in an object, which is responsible for external communications, to > the Statechart constructor function. This allows one to use a mock object in > the unit tests to ensure that the external communications object is being > called at the expected time, with the expected arguments. > <snip/>
As a bit of background on the implementation, Commons SCXML uses the following two predominant ways to interface with processes as part of the SCXML external communications module: * For <send> and <cancel>, an appropriate EventDispatcher implementation is provided which supports all desired send types (before the state machine executor is set in motion, usually at construction): http://commons.apache.org/scxml/0.9/apidocs/org/apache/commons/scxml/EventDispatcher.html * For <invoke>, given its asynchronous nature and complexity, an Invoker [2] is registered for each invoke type (again, before the state machine executor is set in motion): http://commons.apache.org/scxml/0.9/apidocs/org/apache/commons/scxml/invoke/Invoker.html With regards to testing then, Commons SCXML has used a similar approach to date, where JUnit tests check that the desired mock implementations (of EventDispatchers and Invokers as appropriate) are called with the desired params etc. at the desired times (or more accurately, the desired number of times as we don't independently verify delays are accurate in unit tests). Most of the unit tests today deal with <send> though we have some <invoke> tests as well. You can probably search for references to (or implementations of) the two interfaces above in the test source tree and identify such unit tests. There could always be more unit tests and if you're interested in improving the tests on the Java implementation side as well, help is always welcome (though ofcourse, clearly not required from a GSoC perspective -- just as a matter of interest). > However, due to the complexity of the SCXML external communications module, > I think it would also be useful to also write some tests to ensure that > scxml-js statechart instances are able to communicate correctly via HTTP > with Apache Commons SCXML statechart instances, according to the HTTP I/O > Processor specification. > <snap/> Certainly, there'd be a lot of value in doing so. More below. > I'd like to know what kind of automated testing Apache Commons SCXML uses to > test the external communications module; in particular, are only mock > objects used, or is an HTTP server used for testing? I've used Tomcat with > Ant for automated unit testing before, so I know what's involved in that, > but I haven't worked much with Commons SCXML, so it would be good if there > was test code that I could use a reference. > <snip/> As mentioned above, Commons SCXML uses a number of JUnit tests that inject mock implementation of mentioned interfaces for testing purposes, but we do not have any sort of integration tests that play out long running scenarios involving deploying executor instances on a server and posting events using the SCXML message schema etc. So we need to design a testing rig where we can deploy multiple Commons SCXML executor instances on a server as well as a number of scxml-js executor instances on the same or another server with messages going back and forth. A servlet container is probably a good bet since we have to accommodate Java. Maven uses Jetty extensively, so we can look into that (has Ant plugin/tasks as well). So, the setup would include: * Some embodiment of the HTTP I/O Processor (that can interface with the Java and scxml-js libraries) * A startup servlet (or some mechanism) that instantiates a number of Commons SCXML executor instances and some means to also create some number of scxml-js instances * Ideally some meaningful scenarios for the integration tests (if not, a ping with a pong or some simple handshake will do just fine) -Rahul > Let me know what you think. Thanks, > > Jake > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
