<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Not really -- doing so violates abstraction boundaries and processes of such<br>
variety typically do most of their useful work by performing side effects. So<br>
either you have to introduce artificial complexity to satisfy requirements of<br>
the test machinery (highly undesirable) or your test won't really capture<br>
much (but you're still paying the maintenance cost for them).<br></blockquote><div><br></div><div>This is something I am curious about. I am not deeply familiar with any erlang code base and I ask: is it common for Genservers to do side-effects (for example, sending a message to a process which is not the sender)? If not, should there be an OTP behavior for processes that forward messages to others (like returning a list of messages instead of a single reply)?</div><div><br></div><div>tks!<br></div></div><br><div class="gmail_quote"><div dir="ltr">Em sex, 31 de ago de 2018 às 15:24, Jachym Holecek <<a href="mailto:freza@circlewave.net">freza@circlewave.net</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
# Rodrigo Stevaux 2018-08-30:<br>
> If I may ask, I have a question about actor-based systems design that arose<br>
> while writing a simple system for integrating GitHub and Slack.<br>
> <br>
> GitHub events are sent to a server using their Webhook API. We do some<br>
> application logic on the events, and forward them to Slack.<br>
> <br>
> So our architecture is unidirectional: messages are followed from the HTTP<br>
> server to a sequence of processes until they finally get to a message<br>
> dispatcher process that sends messages to Slack.<br>
> <br>
> Message comes in, logic applies, message goes out.<br>
<br>
Erlang comes by default with the brilliant Common Test application, I would<br>
very much recommend giving it a try even if it may take a bit of effort to<br>
learn.<br>
<br>
> The generic servers are very easy to test in a pure fashion: just test the<br>
> return values of handle_call for a given state.<br>
<br>
Not really -- doing so violates abstraction boundaries and processes of such<br>
variety typically do most of their useful work by performing side effects. So<br>
either you have to introduce artificial complexity to satisfy requirements of<br>
the test machinery (highly undesirable) or your test won't really capture<br>
much (but you're still paying the maintenance cost for them).<br>
<br>
> But:<br>
> - unit testing should test that the unit under test forwards a message to a<br>
> given address (and that is not reflected on the handle_call return value)<br>
> - doing the integration testing of a "pipeline" of process involves testing<br>
> that ultimately a message gets to the last process.<br>
<br>
Good questions to be asking -- what assurances do you want to obtain from the<br>
tests and consequently what granularity should you being testing at and what<br>
methods and tools are available to assist. Also: what is the maintenance cost<br>
of these tests looking forward, and does the utility of these justify them?<br>
<br>
Black-box tests, whereby you start the whole thing, tickle its public<br>
interfaces and see the right reactions come out the other end, tend to<br>
always be desirable. You can do this against full cluster, individual<br>
node, individual application, individual process, individual functions.<br>
<br>
Common Test, with project-specific scaffolding around it, will be helpful<br>
at all these levels. With it being ordinary Erlang code running as ordinary<br>
Erlang node all the native communication and diagnostic facilities are also<br>
available to you should you need to inspect or tweak something behind the<br>
system's back. It is also not entirely out of the question for the production<br>
code to be somewhat tweaked to cater for testing needs specifically, where<br>
you can't get your way by more standard means.<br>
<br>
Perhaps too broad an answer... my two cents anyways. :)<br>
<br>
BR,<br>
        -- Jachym<br>
</blockquote></div>