[Proposal] Adding async testing & assertions for capturing N logs to ExUnit

[Michael Pope]

Over the last week, I figured out how to write async tests for capturing multiple logs.  The use case was I wanted to see if N log messages were generated when passing a collection into a process.  While the test code was for a logger my company uses internally, I could basically write the equivalent for the Elixir Logger.

Imagine a test like this...

defmodule MyAppTest do

  use ExUnit, async: true

  import MyCaptureLog

  test "capture 3 banana logs and 2 potato logs" do

    # starts a process that accumulates log messages

    # all logs generated by this logger will be intercepted and accumulated

    {:ok, pid} = SomeLogger.start_link()

    # generate logs without needing a callback

    # logs generated by processes running within the test are isolated within the test sandbox

    _ = for _ <- (1..3), do: SomeLogger.info("I love a ripe banana")

    _ = for _ <- (1..2), do: SomeLogger.info("How would you like your potato?")

    # captures & removes log messages from accumulating process

    assert <captured 3 logs containing the string "banana">

    assert <captured 2 logs matching the regex "potato">  

    # no cleanup "staop_capturing_logs()" is necessary, but it could implemented

    # I think this type of test could be modified to capture standard out I/O, too (but I'd have to investigate)

  end

end

Any interest?  I'm flexible on the syntax, semantics, usability, etc.

[José Valim]

Thanks Michael Pope for the proposal. The biggest issue with such style of capturing is that it can only capture log messages from the test process itself, right?

Given that the logger does receive the PID for the current process, it seems this is doable, so we are interested in seeing an implementation of this feature to move the discussion forward. We can call it capture_self_log for now.

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Director of R&D

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/b3bcebad-6669-4a0a-b2e6-54c8e780cc9e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Pope]

Hi Jose,

Yes, this approach would only work on log messages generated from with
the test. The approach I in my first draft changed the group leader
for the test, so anything started within the test inherited that group
leader leader process. The group leader listens for messages
formatted by a GenEvent in the Logger, and forwards any non-test
messages to the old group leader. There might be another approach
that requires more configuration.

I'll work on a proof of concept that I can open source, and show it to
y'all when it's ready!

Cheers,
Michael

>> email to elixir-lang-co...@googlegroups.com.

>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elixir-lang-core/b3bcebad-6669-4a0a-b2e6-54c8e780cc9e%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "elixir-lang-core" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elixir-lang-core/t5rjU9EYIKQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elixir-lang-co...@googlegroups.com.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2Bf2EZPrOQHcCqcg71MxK9tYgrWCkax8aLFv-UiVWMm_w%40mail.gmail.com.