I attached a simple process which demonstrates the problem.
The service Task has a failedJobRetryTimeCycle of R5/P3M so the job should have a retry of 5. When executing it in a test case the job has a retry of 3.
I debugged this and found out that the expression is first evaluated at execution time of the job.
So if you check the retries of the created job, the returned value will be every time 3, since it is the default retry count.
But at job execution the expression will be evaluated and the correct retry count is set and used.
See the code in the FoxJobRetryCmd.
your test case works for me. I used the process model, which was uploaded from you before.
As delegate for the service task is used a Java class that throws an exception if executed.
Is it possible that you create a test project, which contains the failing test case and the corresponding resources,
so we can reproduce the problem.
See for example this unit test template from thorben.
I analyzed the problem best on the unit test template.
My embedded process engine did not set the FoxFailedJobCommandFactory + ParseListener but the unit test template does so the retry was only set to specified value when executing test with unit test template.
I added this code to my embedded process engine
List<BpmnParseListener> parseListeners = new ArrayList<>();
Now it works but I found no documentation that this is a necessary step.
I also had trouble as I wanted to tune the camunda:failedJobRetryTimeCycle property of some (service) task in my BPM to prevent any retry.
Until I found out after some intensive debugging session, that it requires me to set R0/PT5M or similar on my task (not just R0 nor R0/) and to place a safe-point before the same task (asynchronous before continuation enabled).
Maybe this hint helps you.