We are able to unit test various timers by using the
managementService to query and execute jobs.
However we also want to be able to do exploratory testing - manually triggering (say) a Timer Boundary Event from Cockpit so we can see what changes when the timer would normally execute.
I can’t find any way to do this. We can fake an interrupting timer by moving the process instance to the right part of the workflow - but where there’s something like a non-interrupting boundary timer, where a new process should be started, I can’t see a way to do this, without waiting several days for the timer to hit it’s due date!
Is there something I’ve missed?
Best way would be to create another process which is a script tasks that executes the API command.
Also take a look at: Timer Evaluation: Unit Testing Timer configurations outside of execution. Which was designed for your exact use case.
The Timer Evaluation link is handy - but it’s pretty well what we are doing in our automated tests. What I was looking for was a way to do this in manual tests! As we are building medical workflows, there’s a fair interest in being able to manually check our flows, as well as having automated tests.
I guess we could expose a script that triggers the timer as you say, but it seems quite intrusive, especially as we have quite a few timers.
What we are doing at the moment for manual testing is to have a configuration flag that sets durations to smaller units in the test environment - i.e. a 7 day delay becomes a 7 minute delay in tests. That will be OK for now, but it’d be nice to be able to just use Cockpit to test things in a production-like environment, not rely on configuration hacks.
If you use something like test coverage reporting such as: https://github.com/DigitalState/camunda-coverage-generation-groovy, you might be able to remove the need to create manual tests: as your coverage reports can ensure the business users that their various scenarios are being covered.
Also you can build your “timer execution process” to be dynamic: so that the Start form will do a lookup for all active timers, and you can select which timer to execute. So it should not matter the number of timers you have, they can all be covered as part of a single process.
you can change the duedate of a job: https://docs.camunda.org/manual/7.9/reference/rest/job/put-set-job-duedate/. If the job is persisted in the database, change it with the REST call afterwards to a date that fits your need.
In the next step you can build a cockpit plugin to provide a user interface for this.
Hope this helps, Ingo