<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 16 Aug 2019 at 15:47, Raimo Niskanen <<a href="mailto:raimo%2Berlang-questions@erlang.org">raimo+erlang-questions@erlang.org</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
> But the problem of mocking still remains the same.<br>
> When testing I prefer to mock time so that I don't have to wait for the<br>
> timeout to occur.<br>
> Furthermore, I'm so heavily influenced by my ten years at Motorola that I<br>
> want the timers to stand out as in all the nice SDL diagrams in the<br>
> standards shows.<br>
> That means that I want an easy way to check that a timer has been started<br>
> (mock the call to chronos:start_timer()) and then an easy way to induce the<br>
> expiry of said timer without having to wait for whatever the delay is.<br>
> When you have timers in the minutes range you just don't want your<br>
> automated tests to wait it out.<br>
> <br>
> If there is a way to avoid this with gen_statem I'd be most interested!<br>
<br>
Not today.<br>
<br>
For debugging only, not mocking, it would be possible to log timer actions<br>
in the sys log, and to include timer statistics i.e the number of running<br>
timers or a list of them in sys:get_status/1.<br>
<br>
Would that be interesting fetures?<br>
<br>
For mocking, a possible new feature would be to make the calls to<br>
erlang:start_timer/4 and erlang:cancel_timer/1 pluggable, i.e call them<br>
through fun:s.  Then the plugged in functions may for example communicate<br>
with a registered timer server that can do as it pleases about when to<br>
fire timeouts, log timer starts and cancels, etc...<br>
<br>
How dynamic would such a feature need to be?<br>
* An option to gen_statem:start{,_link}/3,4?<br>
* Read application variable at server start?<br>
* Return an action from the callback module (so the callback module<br>
  can implement a function to activate mocking)?<br>
* Other suggestions?<br>
<br>
Interesting topic - I did not forsee this need...<br>
<br>
BRs<br>
/ Raimo<br></blockquote><div><br></div><div>I like the idea of making the calls to start an cancel timers pluggable.</div><div><br></div><div>The key requirement is that there is a function call that one can detect and that the start of a timer doesn't actually trigger the creation of a timer since one needs the ability to inject the timer expiry into the gen_statem when the test calls for it.</div><div>On that note it might not be good to just expose the erlang:*_timer() functions as they would be un-mockable.</div><div>Maybe something like a call to a dummy function when the timers start/cancel. That can be mocked or spotted by a trace.</div><div>And then a way to inject by using a function in the gen_statem module that would only work in timers_testing mode.</div><div>I would welcome this as an option to gen_statem:start{,_link}/3,4 that one would only use for testing. It should simply turn the erlang:*_timer() calls into calls to those dummy functions.</div><div><br></div><div>This seems like the least invasive way of doing it. And then we can all expect a beer from the first person to ship to production with the testing_timers option ;-)</div><div><br></div><div>Given that gen_statem has introduced the notion of generic timeouts a mechanism such as the above would render Chronos superfluous when it comes to testing timers with gen_statem. </div><div>I would welcome that despite all the help I have gotten from Chronos over the years.</div><div><br></div><div>Cheers,</div><div>Torben</div></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><a href="http://www.linkedin.com/in/torbenhoffmann" target="_blank">http://www.linkedin.com/in/torbenhoffmann</a><br></div>@LeHoff<br></div></div></div></div>