[erlang-questions] Unidirectional architectures in Erlang
Rodrigo Stevaux
roehst@REDACTED
Fri Aug 31 21:37:15 CEST 2018
Great man, I think this is what I was looking after. Exactly this!
Em sex, 31 de ago de 2018 às 16:33, Jesper Louis Andersen <
jesper.louis.andersen@REDACTED> escreveu:
> QuickCheck has eqc_temporal (which is a temporal monad). I don't think
> proper currently implements the interface, but it isn't too hard to write
> it yourself if you want to attack the problem.
>
> You generate random commands like in a statem model.
> The system-under-test (SUT) generates trace events.
> You stuff those trace events into eqc_temporal or equivalent.
> You ask properties of the eqc_temporal trace representation, failing the
> test if the rules are broken.
>
>
> On Fri, Aug 31, 2018 at 9:29 PM Rodrigo Stevaux <roehst@REDACTED> wrote:
>
>> This brings the question, is there a library for writing temporal
>> properties for testing with quickcheck or proper? I mean properties that
>> say something about the sequence of trace messages and not about the
>> contents of the list of trace mssages for example.
>>
>> Em sex, 31 de ago de 2018 às 16:24, Jesper Louis Andersen <
>> jesper.louis.andersen@REDACTED> escreveu:
>>
>>> Hi,
>>>
>>> I've used the sys module more than once, in both debugging and testing.
>>> It is useful, also because you can use sys:log/2,3 to have a trace log of a
>>> running process and inspect it later.
>>>
>>> Another approach I've used is to add trace messages to a system. A
>>> module defines this function:
>>>
>>> report_event(_DetailLevel, _From, _To, _Label, _Contents) ->
>>> hopefully_traced.
>>>
>>> And you call it in your system. Now, you can attach a tracer to this
>>> call in tests and verify the trace you get is what you expect. This allows
>>> you to "see inside" your system and verify its behavior. More advanced
>>> solutions involves rewriting traces into the notion of a temporal monad and
>>> then asking questions on the trace for correctness.
>>>
>>> Yet another approach is to rewrite your code into a computational (pure)
>>> part which sets up a set of actions but has no effect, and an effectful
>>> part which runs said actions. This allows you to scrutinize the actions
>>> without having to bind your system up. Look up, e.g., the Elm architecture
>>> for this approach. The basic idea is that of a free monad: rather than
>>> running the program, return a command set which can be interpreted either
>>> as a test (where the effects are logged) or as a real system (where the
>>> effects are run). We do this at $WORK, which means we can test all of our
>>> stack without ever having to run the system as a whole in unit tests. In
>>> fact, we don't even need a database, or supervisor tree, since we just
>>> simulate the universe around a process. Integration tests are run later via
>>> a QuickCheck like tool written by Martin Gausby - treating the system as a
>>> black box and poking it from the outside to verify we can glue things
>>> together as expected.
>>>
>>>
>>> On Fri, Aug 31, 2018 at 7:07 PM Rodrigo Stevaux <roehst@REDACTED>
>>> wrote:
>>>
>>>> yes, we fundamentally are trying to do integration testing.
>>>>
>>>> unit testing process communication pairwise by sending a message to the
>>>> parent process is something we tried to do and it worked reasonably well.
>>>> but we want to know that the whole composition of processes works well.
>>>>
>>>> the challenge we found on that approach is that the processes have
>>>> names and we would have to find a way to inject the pid of the "next"
>>>> process in the chain and make it the test process during testing and other
>>>> process during production (which can be done with a little bit of
>>>> instrumentation and conditional compiling -- we are on Elixir actually).
>>>>
>>>> is using the "sys" module a regular practice?
>>>>
>>>> thanks for the reply.
>>>>
>>>> Em qui, 30 de ago de 2018 às 20:33, Fred Hebert <mononcqc@REDACTED>
>>>> escreveu:
>>>>
>>>>> On 08/30, Rodrigo Stevaux wrote:
>>>>> >Message comes in, logic applies, message goes out.
>>>>> >The generic servers are very easy to test in a pure fashion: just
>>>>> test the
>>>>> >return values of handle_call for a given state.
>>>>> >
>>>>>
>>>>> That can be done as a regular unit test, yes.
>>>>>
>>>>> >But:
>>>>> >- unit testing should test that the unit under test forwards a
>>>>> message to a
>>>>> >given address (and that is not reflected on the handle_call return
>>>>> value)
>>>>>
>>>>> Aside from using mocks to know that the proper function calls have
>>>>> taken
>>>>> place, you can't easily test the forwarding of messages since that
>>>>> would
>>>>> imply side-effects turning your unit tests into integration tests.
>>>>>
>>>>> >- doing the integration testing of a "pipeline" of process involves
>>>>> testing
>>>>> >that ultimately a message gets to the last process.
>>>>> >
>>>>>
>>>>> Yes and no. You can test that each element of the chain properly
>>>>> forwards data to the right destination. You can do that if you make
>>>>> the
>>>>> endpoint/address/destination for each forwarded message parametrizable
>>>>> or configurable. Forward the data to the test process instead to
>>>>> confirm
>>>>> that the right side-effect has taken place.
>>>>>
>>>>> This lets you test each section of the chain in isolation; then if all
>>>>> sections are well-behaved, you can infer that the whole chain should
>>>>> behave well. You can confirm that with a more naive end-to-end test,
>>>>> knowing that individual components are tested more thoroughly.
>>>>>
>>>>> >Given the maturity of Erlang, I'd expect to promptly find solutions
>>>>> to this
>>>>> >case.
>>>>>
>>>>> On top of the techniques above, you can try using the `sys' module to
>>>>> introspect all OTP behaviours and look at their transitions as a
>>>>> neutral
>>>>> observer:
>>>>>
>>>>> 1> sys:get_status(disk_log_server).
>>>>> {status,<0.75.0>,
>>>>> {module,gen_server},
>>>>> [[{<0.76.0>,'$#group_history'},
>>>>> {'$initial_call',{disk_log_server,init,1}},
>>>>> {'$ancestors',[kernel_safe_sup,kernel_sup,<0.45.0>]}],
>>>>> running,<0.66.0>,[],
>>>>> [{header,"Status for generic server disk_log_server"},
>>>>> {data,[{"Status",running},
>>>>> {"Parent",<0.66.0>},
>>>>> {"Logged events",[]}]},
>>>>> {data,[{"State",{state,[]}}]}]]}
>>>>> 2> P = self(),
>>>>> 2> sys:install(
>>>>> 2> disk_log_server,
>>>>> 2> {fun(_Acc, Event, State) -> P ! {trace, Event, State} end,
>>>>> 2> nodata}
>>>>> 2> ).
>>>>> ok
>>>>> 3> disk_log_server ! fake_data.
>>>>> fake_data
>>>>> 4> flush().
>>>>> Shell got {trace,{in,fake_data},disk_log_server}
>>>>> Shell got {trace,{noreply,{state,[]}},disk_log_server}
>>>>> ok
>>>>>
>>>>> Those won't let you see arbitrary calls being made, but if you have a
>>>>> process chain A -> B -> C, then you can, by looking at the traces of
>>>>> all
>>>>> three processes, track the history of a call and the consequences they
>>>>> have.
>>>>>
>>>>> The sys module is full of really cool functionality few people know
>>>>> about, and that can make live debugging, but also testing much simpler.
>>>>>
>>>>> >
>>>>> >I haven't found a nice solution yet, so I suppose I am using OTP in a
>>>>> wrong
>>>>> >way (maybe it's not a good fit for my project), or I am choosing the
>>>>> wrong
>>>>> >architecture, or that I am missing key knowledge about how to test
>>>>> things
>>>>> >in Erlang.
>>>>>
>>>>> There aren't enough details to know at this point. I frequently just
>>>>> use
>>>>> `meck' (https://github.com/eproxus/meck) as a library, which lets you
>>>>> replace arbitrary function calls through hot code loadig, get traces
>>>>> and
>>>>> counts of all calls and values returned of unmodified code, and so on.
>>>>>
>>>>> If what you're looking for is a way to track side-effects in a very
>>>>> whitebox manner, meck is hard to beat.
>>>>>
>>>>> >
>>>>> >Can anyone shed some light on this questions? Thanks in advance!
>>>>>
>>>>> please provide more details about the nature of the side-effects you
>>>>> are
>>>>> trying to observe in a unit test. My default reflex would be to say
>>>>> that
>>>>> the moment you're testing side-effects, you are doing integration
>>>>> testing.
>>>>>
>>>>> Regards,
>>>>> Fred.
>>>>>
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>
>>>
>>> --
>>> J.
>>>
>>
>
> --
> J.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180831/f844cd36/attachment.htm>
More information about the erlang-questions
mailing list