[erlang-questions] Testing gen_statem timers

[I Gusti Ngurah Oka Prinarjaya]

Hi,

> 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.

For me, you should not use Unit Testing as an evidence to guarantee your
system working well in reality. To do that, you should doing Integration
Testing so you will never met a thing called "Mock" so it can guarantee
your system working well in reality.

Unit testing is excellent for locking your rules, locking your logic flow
so nobody can change your rules, logic carelessly.


Cheers!




Pada tanggal Sab, 17 Agu 2019 pukul 23.44 Micael Nussbaumer <
micaelnussbaumer@REDACTED> menulis:

> Hi, thank you all for your inputs. I ended up doing a trace as Raimo
> suggested and it works fine
> the test
> <https://github.com/mnussbaumer/workforce/blob/3e2498d15ecd3ccc40f5ac982307e1a84a8aa724/test/workforce_tests.erl#L595>
>
> 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.
>
> 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.
>
> 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.
> 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.
>
> 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?
> 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.
>
> 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:
>
> {data,[{"Status",running},
>
>                  {"Parent",<0.86.0>},
>
>                  {"Logged Events",[]},
>
>                  {"Postponed",[]}]},
>
> Anyway, thank you all, great reading your replies,
>
> Micael
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190828/a3c59961/attachment.htm>