commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject Re: [scxml-js] Question on unit testing external communications module
Date Sun, 01 Aug 2010 20:46:54 GMT
On Sun, Aug 1, 2010 at 3:37 PM, Jacob Beard <> 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.

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

 * 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):

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

> 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.

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.

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)


> Let me know what you think. Thanks,
> Jake

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

View raw message