The downside of doing work in setup/0 is if you only need temp dir for one
test, unless you mess with tags which adds boilerplate, you’d unnecessarily
create dirs for tests that don’t need it. But then again you could argue that
if you need it in just one test, do it in that test :) still I think it’s worth
removing boilerplate.
Contrary to the above mentioned golang issue, I am not super concerned about
leaking temp directories, so I wasn’t planning to do that. Though being able to
automatically remove those is arguably the only reason for tight integration
with exunit. As you can see the implementation is currently fairly generic.
I focused on the ex_unit case but a more general utility is interesting too.
About @tag tmp_dir:
@tag tmp_dir: true
test “foo”, %{tmp_dir: tmp_dir} do
seems to strike a good balance between being explicit and easy enough to use. 👍
>> On 27 Jun 2020, at 12:47, Devon Estes <[email protected]> wrote:
>
> What are the rules for deleting this directory after it’s done being used?
> Would it be deleted after the test finishes, or would it remain until the
> user deletes it?
>
> In general this seems ok to me, but it’s also a bit limiting as you only get
> one directory per test. I’d personally prefer to see something where you get
> one directory per process instead of one directory per test, or when each
> call to temp_dir! returns a new, unique directory as this covers some other
> common use cases (like parallel processing of files in multiple folders)
> without having to first create the temp_dir for the test and then in that
> temp_dir additional directories per process. I do this generally using UUIDs
> to create temporary directories, and I haven’t (personally) had any issues
> with debugging or anything, but I can see how this might be confusing for
> folks.
>
> Wojtek Mach <[email protected]> schrieb am Sa. 27. Juni 2020 um 12:19:
>> It’s common to create temporary directories for tests, ideally a unique
>> directory per test to run them concurrently.
>>
>> I’d like to propose adding `ExUnit.Callbacks.tmp_dir!/0` and this is how we
>> could use it:
>>
>> defmodule MyTest do
>> use ExUnit.Case, async: true
>>
>> test "my test" do
>> assert tmp_dir!() =~ "my test"
>> assert File.dir?(tmp_dir!())
>> end
>> end
>>
>> The directory is lazily created on the first call, the second call to that
>> function within the same test simply returns the same path.
>>
>> While the path must be unique per test, I believe it should also be
>> predictable to ease debugging, I picked: tmp/<module>/<test>.
>>
>> To extract the module & test name, we have two options:
>>
>> 1. Define tmp_dir!/0 as a regular function and use stack trace
>> 2. Define tmp_dir!/0 as a macro
>>
>> Here’s a proof of concept for option 1:
>>
>> - the code:
>> https://github.com/wojtekmach/elixir/commit/4c399540802a3cae583c086d865dc90d865df6c8
>> - example of usage in Elixir test suite:
>> https://github.com/wojtekmach/elixir/commit/01df2551582dd9acdaa2f6ff982d6767763070f1
>>
>> The downside of using stack trace is it can easily get mangled, people
>> shouldn’t do this:
>>
>> test "my test" do
>> tmp_dir!()
>>
>> Task.async(fn ->
>> tmp_dir!()
>> end)
>> |> Task.await()
>> end
>>
>> And instead do that:
>>
>> test "my test" do
>> tmp_dir = tmp_dir!()
>>
>> Task.async(fn ->
>> tmp_dir
>> end)
>> |> Task.await()
>> end
>>
>> I believe documenting this might be enough.
>>
>> This proposal is inspired by https://github.com/golang/go/issues/35998.
>>
>> Any feedback appreciated!
>>
>> --
>> 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/066A99E3-B470-44C3-9632-F52E97AB8791%40wojtekmach.pl.
> --
>
> _________________
> Devon Estes
> +49 176 2356 4717
> www.devonestes.com
>
> --
> 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/CAGowJcgGwFrF%2Btf%2BjmKnFSzntuVUX7pLb2Mj4jsvP6XyBXXo%2Bw%40mail.gmail.com.
--
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/90FC5DC2-859B-4BF1-8425-6DC74B770C82%40wojtekmach.pl.
