I considered those options but I don't think they are intention revealing
enough. I feel like I would have to always consult the docs to be sure
which one is which. I would also go with a tuple, since those options do
not really combine.
On Wed, Jan 5, 2022 at 2:20 PM Jon Rowe <m...@jonrowe.co.uk> wrote:
> How about `async: [with: :group]` as "run asynchronously with other tests
> with this group name" and `async: [except: :group]` as "run synchronously
> with this group"
>
> On Wed, 5 Jan 2022, at 10:11 AM, José Valim wrote:
>
> I believe the constraints have not changed on our side. Explicitly saying
> "don't run alongside those files" feels a brittle way of declaring the
> dependencies between tests. Something like "async: :group_name" would work
> better, and that would say "it runs asynchronously but only one within said
> group name". So overall we have:
>
> * if true, runs the tests asynchronously with other modules
> * if false, runs the tests synchronously with other modules
> * if an atom, runs the tests synchronously with modules in the same
> group (atom) and asynchronously with the remaining ones
>
> The big question is: would we want the opposite? If an atom, runs the
> tests asynchronously with modules in the same group and synchronously with
> the remaining ones? And I would say that sounds doable too. So the next
> challenge is coming up with a descriptive enough API that supports these
> scenarios.
>
> One option could be: "async: true | false | {:async_within, :group} |
> {:async_outside, :group}", but I am not pleased about the async
> async_within and async_outside names. We don't need to support all cases
> upfront either, but we should consider the API.
>
> On Wed, Jan 5, 2022 at 10:36 AM Paul Dann <pdgid...@gmail.com> wrote:
>
> On Tue, 30 Nov 2021 at 12:27, Paul Dann <pdgid...@gmail.com> wrote:
>
> On Fri, 26 Nov 2021 at 20:22, José Valim <jose.va...@dashbit.co> wrote:
>
>
> To be clear, I understand and agree with the problem, but I don't agree
> with the solution because it is not ultimately solving the problem at hand.
> For example, speaking about Ecto, you could also use Mox, which also has an
> ownership-like mechanism, similar to Ecto's. You could define a behaviour,
> provide a default value for said behaviour, and then mock it in specific
> tests. This means your tests can run concurrently all the time. However,
> that sounds like overengineering for something as simple as reading the
> application environment. In any case, I hope it provides another frame of
> reference.
>
>
> Quite right - I do in fact rely on fakes quite extensively to support
> tests, but many of the tests I'm considering are intended to test database
> queries, so I can't really fake them out. I honestly haven't yet looked in
> detail at Mox, so if it has some kind of checkout mechanism that could act
> as a semaphore, I suppose that could be a possible path to a solution
> (maybe a bit heavy), but as I said I'm not really looking to mock the
> global state, just serialise tests in groups according to the global
> resources they touch.
>
>
> I spent some time recently trying to solve this problem by looking into
> whether I can scope database access to specific tests. Inspired by Mox, I
> looked into using $callers to track pids. The problem I have is that the
> data store I'm using (ElasticSearch) does not have transaction support. I'm
> experimenting with scoping the actual _name_ of indexes (tables) used for
> each test, but indications so far are that it's unlikely this could work
> transparently, which leads me back to a situation where tests need to be
> explicitly tagged in some way as accessing a particular shared storage in
> order to set up the namespacing required to prevent collisions. This is
> exactly the same kind of tag curation that exclusion groups would require,
> and probably actually introduces more complexity.
>
> Ultimately, maybe I should just give up on async tests for this project,
> but it seems like a viable solution is frustratingly close. I agree that
> exclusion groups would require care to prevent race conditions, but I'm not
> seeing a good alternative when the database itself doesn't have transaction
> support, and can't be mocked due to the queries themselves being under test.
>
> Paul
>
>
> --
> 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/CALZj-VpAEpeLGTD-de2nW6Gyyxew%2Bk%3De1GDJKWEkOMd9PKeXcA%40mail.gmail.com
> <https://groups.google.com/d/msgid/elixir-lang-core/CALZj-VpAEpeLGTD-de2nW6Gyyxew%2Bk%3De1GDJKWEkOMd9PKeXcA%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 elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KJpPPucGKJYffMxBT82nd5F4x640rEzwK86sokrR-Zgw%40mail.gmail.com
> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KJpPPucGKJYffMxBT82nd5F4x640rEzwK86sokrR-Zgw%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 elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/6d006e1a-f653-482e-9704-607f4cda951e%40www.fastmail.com
> <https://groups.google.com/d/msgid/elixir-lang-core/6d006e1a-f653-482e-9704-607f4cda951e%40www.fastmail.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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2B97Z6eUuesa%3DtX3iXeY-gEqmTbhJKR2JuMhSmkvmeXkQ%40mail.gmail.com.
