This is part of the tutorial Tutorial - Service invocation plugin

• Previous step: 4. Service invocation

Updating unit tests

Finally after updating the service invocation, we'll rerun our unit tests. As we've changed some of our activity outputs, the test case ExampleActivityTest.executeAsync will fail.

The reason for this failure is that the unit test is requesting a String for the moreOutputs port, but now we've changed it to be an error document.

Error documents normally hidden from activities From within the Activity code, you would not normally have to deal with references being error documents, or lists containing error documents. The reason for this is that the ErrorBounce layer of the Processor dispatch stack will prevent invocation if any of the input ports to the service is an error or contains an error. Instead the ErrorBounce layer will produce new derived error documents are produced on the output ports. The new error documents contain references back to the original error. This layer is also responsible for creating such error documents on the output ports when callback.fail() is called. If your activity want to take full control over errors, you will need to modify the user interface code to remove the ErrorBounce layer from the dispatch stack after the activity has been added to a Processor.

To work around this unit test error, replace the code snip with:

Rerun the test, next error is:

This is our checksum of the empty binary array. To double check, you can run in a Linux terminal:

So we'll replace the expected value simple:

with da39a3ee5e6b4b0d3255bfef95601890afd80709:

We see that the line below checking for "Value 1" and "Value 2" in moreOutputs will also fail:

To inspect the error document, change the moreOutputs assertion to:

Finally our unit test will pass - but we notice also that we are not testing the service with actual binary data connected to the extraData port. Let's make a copy of the whole executeAsynch() test method and call the copy checkSumOfExtraData. Don't forget the @Test annotation!

To force the optional input port, before the activity.configure() call, add:

The additional input of byte arrays:

The new output port:

Update to expect 3 output ports:

We'll calculate what we think the new checksum should be in a Linux terminal (remember there's no line breaks in the test strings):

So update:

And add:

Resulting in:

If your unit tests now all pass, feel free to play around with your new checksum activity in Taverna. You could try to recreate this workflow:

This completes the Service invocation plugin tutorial. Next you might want to have a look at the how we make the service appear in the user interface, exploring that myfancytool-activity-ui module.

This is part of the tutorial Tutorial - Service invocation plugin

• Previous step: 4. Service invocation
• Next tutorial: Tutorial - Service discovery plugin