Hey Mix config is global mutable state, so I'm not sure how you could handle this asynchronously.
Personally I prefer to avoid mix config where possible an instead pass values down through the supervision tree. :) Cheers, Louis On Fri, 26 Jan 2018, 16:03 Michael Schaefermeyer, < michael.schaeferme...@gmail.com> wrote: > It definitely is, thanks Louis! > > Figuring that this is something other people might need as well I wondered > if it was worthwhile to put it ExUnit directly (and make it work with > async). > > > Am Freitag, 26. Januar 2018 16:41:47 UTC+1 schrieb Louis Pilfold: > >> Hi Michael >> >> I've written a tiny lib for this -> https://github.com/lpil/temporary-env >> >> Perhaps you might find this useful :) >> >> Cheers, >> Louis >> >> On Fri, 26 Jan 2018, 14:24 Michael Schaefermeyer, < >> michael.sc...@gmail.com> wrote: >> > Hey all, >>> >>> I regularly find myself changing the Application configuration in tests >>> to temporarily adjust a setting (i.e. when using Bypass and changing the >>> configured endpoint for HTTP requests). >>> >>> My current workflow looks as follows: >>> >>> test "something" do >>> old_env = Application.get_env(:app, Module) >>> new_env = Keyword.put(old_env, :key, value) >>> >>> Application.put_env(:app, Module, new_env) >>> >>> # Do something that reads the config >>> Application.put_env(:app, Module, old_env) >>> end >>> >>> Besides being quite repetitive it disallows async tests, as another test >>> might be reading from the Application environment while this test is >>> running. >>> >>> Ideally, ExUnit would allow me to temporarily change the Application >>> environment in a async-safe way: >>> >>> test "something" do >>> with_application_env :app, Module, fn(config) -> Keyword.put(config, : >>> key, value), fn -> >>> # Do something that reads the config >>> end >>> end >>> >>> Of course I could make the configuration module configurable and use >>> something other than Application. The reason I am still suggesting this is >>> that I feel like configuring your app via Application is still the way to >>> go and I wouldn't want to diverge from that standard just for tests. >>> >>> Hope that makes sense. I would love to hear your thoughts. >>> >>> Thanks, >>> Michael >>> >>> -- >>> 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-co...@googlegroups.com. >> >> >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elixir-lang-core/4b863c84-2062-42f3-b0a0-92b1d122f40c%40googlegroups.com >>> <https://groups.google.com/d/msgid/elixir-lang-core/4b863c84-2062-42f3-b0a0-92b1d122f40c%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> 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 elixir-lang-core+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/4eacd1d3-0d61-499a-bf82-076988799a53%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/4eacd1d3-0d61-499a-bf82-076988799a53%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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 elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CABu8xFD%2BqTPzmJzt36PoC%3Dqm8gTZZUpwcemN%3DM5HMxn_nF_dUw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
