clientTrack: new option for aborting partnerTracks after completing its execution?

[Antonio García Domínguez]

Hi everyone,

We have a template-based BPTS testing a composition that will sometimes invoke the mockups twice, and sometimes only once. We can't really know this in advance without duplicating the logic inside the composition. Just in case, we've duplicated some of the activities in the partner tracks. This makes tests in which the mockups are invoked only once much slower, though, as BPELUnit insists on waiting for all activities even after the <clientTrack> is done. We're not using any receive conditions, by the way: we only want to exercise the composition in order to collect execution logs (for dynamic invariant generation) and/or all messages sent from the composition (for mutation analysis).

This behaviour is fine for regular tests, but in our case we'd like to make BPELUnit abort every activity in the <partnerTrack>s after the <clientTrack> finishes its execution, to speed up the test suite. Since we don't want to change the default behaviour, perhaps we could add an optional abortPendingActivitiesWhenDone attribute to the <clientTrack> element. If set to "true", it would enable this new behaviour.

What are your thoughts on this?

Best regards,

Antonio

[Antonio García Domínguez]

Hi again,

I've changed my mind on this. I think it'd be better to simply extend ITestResultListener with methods for notifying that a partner/client track started or ended, and have a custom test listener abort the test if deemed necessary. This could be useful for other things, such as the Eclipse UI.

I'm currently testing a few commits which add this feature. If all goes well, I'll push the changes to bluezio/master and bpelunit/master, as usual.

Best regards,

Antonio

[Antonio García Domínguez]

Hi again,

I pushed the changes, but after looking a bit more at the code I noticed the progress(ITestArtefact) method. Seems we won't be needing this after all :-D.

I've reverted the changes in bpelunit/master and bluezio/master now. Sorry for the trouble :-).

Antonio