<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 16, 2019 at 7:07 AM Jesper Louis Andersen <<a href="mailto:jesper.louis.andersen@gmail.com">jesper.louis.andersen@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">Second, timers are the scourge of testing. They are side-effects which means they are usually handled by mocking. And mocking is never the answer if there is a decent way around it. However, if a timer turns into a message, then we can choose to have timers handled outside the component and then send messages into the component. This helps testing, as we can run with a time-compression component, removing typical long waits in our test cases. In fact, separation of effects from computation is almost always a win for code in general.</div><div style="font-family:arial,helvetica,sans-serif"><br></div></div></div></div></blockquote><div>This has been my general go-to strategy, but note that this isn't really doable with a gen_statem since the timer events have their own type of message, which you cannot fake in a generic manner (the same way you would just do it with a timeout message in other behaviours). You at the very least need to add a special injection-creating callback that uses the next_event action to inject a timeout of the type you want, and the way -ifdefs work in Erlang, that clause can't optionally be compiled out for production.</div><div><br></div><div>Other types of mocking or time handling otherwise need to be aware of implementation details in gen_statem to know which clocks to mock and advance.<br></div><div><br>
</div></div></div>