Testing a boundary timer

I am trying to test a boundary timer with a Spring boot application.

I want to test the a non-interrupting boundary timer which goes to a message end event.

I have an example with a failing test.

This seems simple enough. Is it supported?

image

If you’re using the camunda-bpm-asserts lib then, when you get that point in the process you can use
execture(job()) https://github.com/camunda/camunda-bpm-assert/blob/master/docs/User_Guide_BPMN.md#executing-jobs

That will move the token through the boundary event.

@Niall Thank you for your response.

I don’t want the external task to complete. I want the boundary event to fire based on a timer if the user task has not been completed in some certain time.

I updated the repo because I had a service task instead of a user task.
Please take a look with the new commit.

image

I fixed the happy path tests. No more history level problems. Just trying to figure out the timer.

@Niall I tried adding execute(job()) after I move the time forward but it completes the timer task no matter how much I move the time forward by.

I have the timer for 1 day. If I move the time forward by 1 hour the timer still fires.

I understand the ClockUtil only moves the time forward and the engine must need some instruction to evaluate again based on the time but I am not clear how to do it. I did a search for “ClockUtil” in the camunda-bpm-assert repo but there is no example.

I searched the forums and found this Testing timer events in processes but it is similar to what you are saying.

Why are you moving the time around at all?
Just complete the timer manually.

It doesn’t seem worthwhile to write a unit test and execute a task manually if I am trying to test a timer. I want to move time forward and verify that a timer fires. That would closely mimic a real testing scenario.

I don’t understand the point of ClockUtil then. What is the point of moving time forward if timers do not trigger?

OK I see this is quite complicated and not supported out of the box.

I see this custom code for testing: Timer Evaluation: Unit Testing Timer configurations outside of execution

This seems like a big missing area in the testing library though.

What exactly are you trying to test? that your process works or that the engine’s implementation of the timer event works?

also:

There is no need to execute the manual task to test the timer, i’m not sure what you mean by this.

I mean that triggering the timer in code does not test the time based aspect of it.

Your suggestion is to put a test in the code that says “timer is configured for 1 day” and trigger it manually instead of moving time forward one day and seeing that the timer triggers.

I suppose that is fine, it is a test of the BPMN diagram configuration.

Regarding this, when I used execute(job()); it made the process wait at only the message send event. It marked the UserTask complete. So I need to run a more specific method to only trigger the timer task in that case?

Because the execution should be waiting at 2 places, the user task and the message event which is a service task.

Sorry I had an interrupting timer instead of non-interrupting in my diagram. So that part is clear.

I used a Query to trigger only the timer and things are working.

So the engine in test mode does not support time based triggering, we will adjust our tests accordingly.

Am I just not using the proper testing library? I see a time based example in the bpm scenario README.

Anyway I am embarassed I did not see the example in the https://github.com/camunda/camunda-bpm-assert-scenario. It is really great.

1 Like

Hi @ankur.sethi,

with camunda-bpm-assert you can write in your JUnit tests either:

assertThat(processInstance).isWaitingAt("").job().hasDueDate(expectedDueDate);
execute(job());   

or

assertThat(job().getDuedate()).isCloseTo(new Date(), 300000);
execute(job());   

to check the due date of the job and fire the job immediatly. This will work for “Wait 2 weeks”, too.

If you don’t want the timer to be fired, skip the execute(job()).

Hope this helps, Ingo

4 Likes