[erlang-questions] Testing gen_statem timers

[Raimo Niskanen]

On Thu, Aug 15, 2019 at 12:33:03PM +0100, Micael Nussbaumer 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

For the current code on maint and master (I think):

If you trace gen_statem:loop/3; the third argument is a #state{} record
whose 3:rd field (3:rd record field - 4:th tuple field) are the timers.
The timers is a 2-tuple with two maps; one Ref => Name and one Name => Ref.
You might observe these maps and verify that they do not grow.

It should be possible to write a trace match spec that filters out and only
delivers this field to the tracer.

> 
> *M*icael *N*ussbaumer
> artistic portfolio <http://cargocollective.com/micaelnussbaumer>


-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB