we have two process applications AppA and AppB, each having its own process engine but sharing the process database. AppA contains the process model A, AppB contains the process model B. AppA does not contain the process B.
The process B expects some input variables when started and produces some output variables when it’s finished, i.e. it behaves like a method with an input and output parameters.
Process A has a Call Activity that calls the process B.
A quite common setting so far, I assume.
Now I’d like to write a unit test for the process A. But the test fails when the process B is called, since B is not a part of AppA.
I’d like to somehow mock/stub the call activity so that it does not try to start the process B but instead just puts some canned variables into the scope of process A (thus stubbing the process B). Is that possible (and how)? Do I have to dig deep into the internals of the process engine to do that?
I’ve seen these two threads with somewhat related questions but there the people do not “think in the same direction” as I do.
BTW: There is a typo on the front page of that project. It reads ProcessExpressions.registerSubProcessMock but it should be ProcessExpressions.registerCallActivityMock IMO.
Now I’ve got the next problem. In the calling process / call activity, we specify “versionTag” as the binding and specify a concrete value for the versionTag of the model to call.
But when mocking the call activity, it’s not possible to specify the version tag for the mock. Only process key is possible.
Hence, when the main process is executed, the engine throws the following exception:
no processes deployed with key = '<snip>', versionTag = '<snap>' and tenant-id = 'null': processDefinition is null
I tried to set the versionTag of the faked model via the repository service (find the model using a query, then downcast to ProcessDefinitionEntity, then call setVersionTag("myVersion")) but it did not help since the change seems to stay local in my program and does not get propagated to the engine.
Another way you might approach this is to just have the subprocess created, by deploying it along with the main process in the test. Make sure its start event or something very early in the process is asynchronous if you can. Then use the modification API to go into the spawned process instance and move it straight to its end event. Set the variables you’d like to mock and execute back into your main process.
Thank you for your ideas. But it’s was too complicated for the goal I pursue. I’d rather write a similar code to the library, and add the things I miss.
