(Mox) testing guidelines?

[thbar]

I am going to implement a bit of tests for a Ecto handler triggering AppSignal custom metrics.

For some context, see:

• Track ecto queue time separately #318 (comment) (which I'm basing my implementation on)
• Are calls to add_distribution_value synchronous or asynchronous? Can they raise errors? #887

I would like to add a bit of tests specifically on that handler, and a bit of Mox'ing around AppSignal.

The thing is unless I missed it, I do not see @behaviour/@callback in AppSignal which would let Mox work here.

I could create a small wrapper around the functions I'm interested in, like:

appsignal-elixir/lib/appsignal.ex

Lines 145 to 151 in 34e6751

	@doc """
	Add a value to a distribution
	Use this to collect multiple data points that will be merged into a graph.
	"""
	@spec add_distribution_value(String.t(), float | integer, map) :: :ok
	def add_distribution_value(key, value, tags \\ %{})

but I wonder if there is some testing facility that could help here.

Typically, I would attach, during the test, the handler via a unique handler id like done here:

https://github.com/dashbitco/broadway/blob/main/test/broadway_test.exs#L311-L318

and would issue a couple of calls on Ecto (working in a sandbox), and assert that AppSignal has received the right calls (in that case the SUT or System Under Test would be the telemetry handler module I'm writing).

Of course in the example described in #318 (comment), there is no big risk to ship this, but as we add more (varied) custom metrics, it will be beneficial to be able to implement such tests, in particular to catch integration troubles on package upgrades, for instance.

Are there some guidelines on how to test around AppSignal?

Should I just create a small wrapper with the same typespec & Mox that, since we control it, or is there something better?

Thanks!

[unflxw]

Hi @thbar!

I am not very familiar with Mox, so my answer here may miss the mark.

Internally, to test AppSignal, we make it so that modules reference other modules via attributes, the values for which are obtained from our configuration. Then we implement fake modules that provide the same API, and our test environment configuration loads those fake modules, which store the values that they receive when called, so that our tests can make assertions on how they were called.

This seems very similar to what Mox does, going by their documentation -- the big difference, of course, being that Mox creates the fake modules automatically for you.

So, yes, you could create a thin wrapper around AppSignal that defines attributes for methods in the way that Mox expects, then ask Mox to create a mock for it. If you're already using Mox throughout your test suite, this is probably the solution that is more in sync with how your test suite already handles these problems.

But you could also use our FakeAppsignal module, or create your own without Mox -- though do keep in mind that we don't consider the fake module itself part of our public-facing API, and we might change it at any time for any reason (but we probably won't)

[thbar]

@unflxw sorry for the long delay - thank you very much for your input, I will have a closer look at see where we can go from there!

[unflxw]

No problem at all! Thank you for always asking such thoughtful questions 👍