Reliable way to test Process.send_after/4

Questions / Help
, ,
1

I have a few genservers that need to fetch some data from an external resource every 15 minutes. The solution I’m using is just plain Process.send_after/4.

The problem is when it comes to testing.

The way I did it in the past was to make the interval configurable and set it to something like 100ms and check for updates with Process.sleep/1 in tests. This works, however this seems more like a hack to me and slows down tests considerably if you have a lot of tests like this one, not to mention that it makes tests flaky in case the genserver is doing a lot of work.

Is there a better way to do this kind of testing?

2

Testing things that happen in isolation within an external process can either be polled (sleep) or you make the process inform the test (it sending a message when it did the thing). Your option here really is the latter.

I lately have sometimes gone the way of doing the latter through telemetry. I add a telemetry emit to the thing I’m interested in and in the test add a handler, which sends a message to the test process. I like this one for it being very not a home grown system, not specific to the tested process and also generally being a useful guidance on where telemetry might be useful given I also want to test it.

2 Likes
3

I don’t think your ‘configurable timer’ approach is too bad - why not set it to 1ms?

Other options include calling the genserver callback functions directly from your test process (you have to construct the state parameter yourself), but it rather depends on exactly what you want your tests to demonstrate.

2 Likes
4

Nice idea. I’ve found use-cases where I was finding it hard to test some functionality without breaking encapsulation. The problem is that the telemetry approach suffers from the same synchronization problem, I would ideally love to have some API that would allow processing of send_after instantly in a controlled way.

Setting it to 1ms will result in tests randomly failing. Since the mailbox is always sequentially processed, there is no guarantee that the message will be processed exactly after it was sent.

Not exactly sure what you mean by this, care to show a small example?

5

I use mox for that.

defmodule Recurrent do
  @callback send_after(pid(), any(), non_neg_integer()) :: :ok
end

defmodule Recurrent.Impl do
  @behaviour Recurrent
  @impl Recurrent
  def send_after(pid, message, milliseconds),
    do: Process.send_after(pid, message, milliseconds)
end

That way you already have a single place to do whatever else while sending a message, like telemetrying it, or writing a log, or something. The testing becomes as easy as defining a mock for it.

3 Likes
6

I like this approach, it might be one of the best out there!

For some reason I am always hesitant about using mocks for anything besides external calls, but in this case it makes perfect sense.

7

Do you have a complete example at hand that we can check?

8

In finitomata I mock my own internals to provide a fancy testing framework for the library via Finitomata. ExUnit. In a nutshell, it implements a listener which sends a message back to the test process, making it possible to simply assert_receive/2 in it.

2 Likes