<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi, thank you all for your inputs. I ended up doing a trace as Raimo suggested and it works fine</div><div dir="ltr"><a href="https://github.com/mnussbaumer/workforce/blob/3e2498d15ecd3ccc40f5ac982307e1a84a8aa724/test/workforce_tests.erl#L595">the test</a><br></div><div dir="ltr"><br></div><div>I think I could also have implemented `format_status` for the gen_statem and extract the timers tuple from it? Not sure. Regarding having an API for it I think it could be useful since that implementation detail is opaque.</div><div><br></div><div>Torben, thank you sharing your lib - it looks like it can be quite handy but in this particular case it's for a library as well and I would rather not use a dependency, and since the timer options in the gen_statem work great by default I would like to keep using those instead of incurring another message to set the timer & executing a callback. I can definitively understand the appeal of having it instead be mockable though. </div><div><br></div><div>For the timeouts when I wrote the module that uses these timers I added the option of setting their value on start, so that indeed I would be able to test the behaviour easily in terms of ms and for that part it works great. It was just this detail that was bugging me.</div><div>On the other hand, mocking also introduces a layer of "this passes the tests but in reality it's not being tested" correct? I'm not very familiar with mocking in tests.</div><div><br></div><div>Roger, thank you so much for taking the time to extract that! So I ended up doing the state inspection instead, I haven't used dbg yet but it looks like it can be useful. What is the difference between using dbg instead of the bare trace? </div><div>I guess now by looking at your example that indeed I could have done the same approach by tracing the timer sets/cancels instead of tracing the call functions and extracting the state, that is probably cleaner. </div><div><br></div><div>Raimo, I replied to you by accident privately when using the list web gui - I thought it was going to the "thread" as a reply to you. And yes, perhaps on the sys:get_status it could include by default/on option also an element for the timers? I did in fact try calling that at some point after your first reply:</div><div><span style="background-color:rgb(255,255,255)"><font color="#000000"><br></font></span></div><div><p style="margin:0px;font-stretch:normal;line-height:normal"><span style="font-variant-ligatures:no-common-ligatures;background-color:rgb(255,255,255)"><font color="#000000" face="arial, sans-serif">{data,[{"Status",running},</font></span></p>
<p style="margin:0px;font-stretch:normal;line-height:normal"><span style="font-variant-ligatures:no-common-ligatures;background-color:rgb(255,255,255)"><font color="#000000" face="arial, sans-serif">                 {"Parent",<0.86.0>},</font></span></p>
<p style="margin:0px;font-stretch:normal;line-height:normal"><span style="font-variant-ligatures:no-common-ligatures;background-color:rgb(255,255,255)"><font color="#000000" face="arial, sans-serif">                 {"Logged Events",[]},</font></span></p>
<p style="margin:0px;font-stretch:normal;line-height:normal"><span style="font-variant-ligatures:no-common-ligatures;background-color:rgb(255,255,255)"><font color="#000000" face="arial, sans-serif">                 {"Postponed",[]}]},</font></span></p></div><div><span style="background-color:rgb(255,255,255)"><font color="#000000"><br></font></span></div><div>Anyway, thank you all, great reading your replies,</div><div><br></div><div>Micael</div></div></div>