I would say this definitely fits 2) - we use it in multiple test suites in Elixir, it is just that the person who implemented this at the time (read: me) did not think about abstracting it properly before.
That same person then proceeded to copy the same helpers to multiple other apps. :P On Mon, Jun 29, 2020 at 8:45 AM Devon Estes <[email protected]> wrote: > I think in general the two questions to ask for this are > > 1) can this be part of a library instead of added to ExUnit, and > 2) is this needed for the development of Elixir itself > > right? > > It seems to me like this isn’t needed for the development of Elixir > (although It would make some tests nicer/easier) and it’s definitely > possible for this to be part of a library (maybe it could be included in > assertions? > https://hexdocs.pm/assertions/Assertions.html), so it seems to me like > this might not be needed in ExUnit itself. > > Mach <[email protected]> schrieb am Mo. 29. Juni 2020 um 07:31: > >> >> What about supporting a new annotation @setup that can be used to call >> tmp_dir but also custom functions in the test suite, which would be useful >> to fine-tune setup for specific tests, especially for expensive setups. Eg: >> >> @setup tmp_dir: "my_tmp_dir", :do_something_expensive >> @tag :slow >> test "my test B", context do >> end >> >> >> I don’t think we need the `@setup` tag as I believe we can achieve what >> you have in mind with describes and their own setups: >> >> @moduletag :tmp_dir >> >> describe "foo" do >> setup [:expensive] >> >> # ... >> end >> >> What do you think? >> >> @tag is a filter (as stated by the doc), so enabling it to run >> setup/actions sounds like mixing up responsibilities and AFAIK it wouldn't >> be extensible to support custom setup functions like described above. >> >> >> FWIW, we also have :capture_log and :timeout tags that are more than just >> filters. :) >> >> >> Is it too overkill or does it make sense? >> >> On Saturday, June 27, 2020 at 7:43:37 AM UTC-4, Wojtek Mach wrote: >>> >>> Here is a proof of concept for the tag-based solution: >>> https://gist.github.com/wojtekmach/2c59fb3c3c1c274e35d164014662975a >>> Of course it would be slightly different as part of ExUnit, but you get >>> the idea. (And you can play with _this_ in your projects right now!) >>> >>> On 27 Jun 2020, at 13:17, Wojtek Mach <[email protected]> wrote: >>> >>> 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 >>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGowJcgGwFrF%2Btf%2BjmKnFSzntuVUX7pLb2Mj4jsvP6XyBXXo%2Bw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> >>> >> -- >> 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/d7fb19b1-d06c-4587-a609-f07b3b7ff8b9o%40googlegroups.com >> <https://groups.google.com/d/msgid/elixir-lang-core/d7fb19b1-d06c-4587-a609-f07b3b7ff8b9o%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> -- >> 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/0A935EC4-BBF3-4351-88AB-0B2EE800B7F1%40wojtekmach.pl >> <https://groups.google.com/d/msgid/elixir-lang-core/0A935EC4-BBF3-4351-88AB-0B2EE800B7F1%40wojtekmach.pl?utm_medium=email&utm_source=footer> >> . >> > -- > > _________________ > 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/CAGowJcgiR%3DszA2fbZzx_FLNjvw2JLZ59N_xb%3DHfschnwwDoKdg%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAGowJcgiR%3DszA2fbZzx_FLNjvw2JLZ59N_xb%3DHfschnwwDoKdg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAGnRm4KoDUc-FAEg_0jSe-CYNwj%3D8GUg0A%2BW7ZLP13717x7qjw%40mail.gmail.com.
