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 On Thu, May 25, 2017 at 1:26 PM, José Valim <[email protected]> wrote: > 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 > > On Thu, May 25, 2017 at 9:11 PM, Michael Pope <[email protected]> wrote: >> >> 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. >> >> -- >> 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 [email protected]. >> 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 > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2Bf2EZPrOQHcCqcg71MxK9tYgrWCkax8aLFv-UiVWMm_w%40mail.gmail.com. > > For more options, visit https://groups.google.com/d/optout. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAKswC8gF6GEfxaWWktaq_K4J2y%3D21WAk9TALjCuLRR4x6rZ5kQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
