[erlang-questions] Testing gen_statem timers

Torben Hoffmann torben.lehoff@REDACTED
Fri Aug 16 12:36:29 CEST 2019


On Fri, 16 Aug 2019 at 10:43, Raimo Niskanen <
raimo+erlang-questions@REDACTED> wrote:

> On Thu, Aug 15, 2019 at 06:44:43PM +0200, Torben Hoffmann wrote:
> > Hi Micael,
> >
> > I'm very biassed here, but apart from my creator fondness many of my
> > colleagues are very happy about the approach that my Chronos library
> takes
> > when it comes to timers.
> >
> > https://github.com/lehoff/chronos
>
> I notice that in that README.md you compare Chronos with the timeout
> feature
> in gen_server and gen_fsm.  The timers in gen_statem were specifically
> designed to remedy most of their shortcomings.
>
> So, from a usability point of view, can you elaborate what Cronos
> can do better than gen_statem timers?
>
> I have a todo to update the README.md to cover gen_statem as well - thanks
for reminding me!

I have worked a lot with gen_statem - absolutely a very good component and
easy to work with.
But the problem of mocking still remains the same.
When testing I prefer to mock time so that I don't have to wait for the
timeout to occur.
Furthermore, I'm so heavily influenced by my ten years at Motorola that I
want the timers to stand out as in all the nice SDL diagrams in the
standards shows.
That means that I want an easy way to check that a timer has been started
(mock the call to chronos:start_timer()) and then an easy way to induce the
expiry of said timer without having to wait for whatever the delay is.
When you have timers in the minutes range you just don't want your
automated tests to wait it out.

If there is a way to avoid this with gen_statem I'd be most interested!

Cheers,
Torben


> >
> > Basically, don't use the internal timers, but do read the full README
> from
> > Chronos.
> >
> > Very happy to assist you and improve anything in Chronos, if you find it
> > confusing.
> >
> > Cheers,
> > Torben
> >
> > On Thu, 15 Aug 2019 at 13:35, Micael Nussbaumer <
> micaelnussbaumer@REDACTED>
> > wrote:
> >
> > > Hi, first time poster (but I've read many threads in here).
> > >
> > > How does one usually test gen_statem internal timer events?
> > > Usually you test the effects of the behaviour somehow, and I can test
> > > that. But in this particular case I had a situation where timers with
> uniq
> > > references are created, later on they usually get removed and all is
> fine -
> > > they're created for each extra worker started and at some point the
> worker
> > > is removed by the timer event that trigger checking some conditions.
> > >
> > > I noticed after that, the way I had written it, if an extra worker was
> > > started then died for some other reason than the timer event taking it
> out,
> > > I could theoretically accumulate timers that wouldn't be removed, I've
> > > since then corrected that but still I have no tests ensuring me that it
> > > actually works.
> > > So my question is if there's any even way to test it (even if with
> > > tracing)?
> > > Thanks
> > >
> > > *M*icael *N*ussbaumer
> > > artistic portfolio <http://cargocollective.com/micaelnussbaumer>
> > >
> >
> >
> > --
> > http://www.linkedin.com/in/torbenhoffmann
> > @LeHoff
>
>
> --
>
> / Raimo Niskanen, Erlang/OTP, Ericsson AB
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>


-- 
http://www.linkedin.com/in/torbenhoffmann
@LeHoff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190816/e97c2c0c/attachment.htm>


More information about the erlang-questions mailing list