Thanks to everyone that provided any kind of feedback on Part I. It is reassuring to know that automated testing is a focus for so many people. Please nudge IBM at any available opportunity to provide a clearer vision on, and better support for, automated testing.

Service Testing is essentially unit testing for IBM BPM. It’s by Developers and for Developers (whereas Process Flow Testing would be by Users for Developers).

There are many ways to create, manage and execute unit tests in IBM BPM. In isolation, the approach I will outline here seems a little contrived but (in my view) it’s more than justified by the benefits of having all my automated tests (i.e. including the other types of automated test) defined, executed and reported on in a unified manner.

So, looking back at the example from Part I, here’s a Service:

The interface looks something like this:

Here are a bunch of tests:

Finally, here is some glue code for the statement above:

It’s very simple. For a given input, I expect a certain output. It might not really be the “done thing" to use JSON in Gherkin but, like I said before, these tests are by Developers and for Developers.

Sometimes, Services are more stateful (and require a slightly different approach). I will talk about this in a future blog about Integration Testing.

It’s important to build and design services with testability in mind. Try to avoid tightly coupling stateless atomic operations with more stateful ones e.g. don’t embed code to record the outcome of the decision service above directly into the decision service itself. You want to be able to test your decision logic without invoking the recording mechanism.

It’s an appealing line of thought to question the value is of creating these tests. Many of them can seem mundane to create and you might expect that they will never fail. You may be right that some will never fail but I personally promise you that, if you follow this path, it will not be long at all before an automated test helps you out; either by finding a bug early or by giving you the confidence to undertake some refactoring that you might have otherwise avoided.

Developers are lazy (I say this as a Developer). Smarter developers realise that automated testing provides delayed gratification.

My advice to Lead Developers is this…

It should be super-cool if Watson could turn it’s attention to my IBM BPM process server and take some notes on the execution of services and the data flowing in and out. Then, after some thought, it would check out my feature file and update my tests to reflect it’s observations.