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.
