> async: true | false | {:async_within, :group} | {:async_outside, :group}
Best ideas I can come up with are *async: {isolate: :group}*, and *async:
{alongside: :group}*, but not sure how much better that is.
On Wednesday, January 5, 2022 at 8:39:39 AM UTC-5 José Valim wrote:
> To be clear, I think my initial suggestions are bad too. Especially
> async_outside. :)
>
> On Wed, Jan 5, 2022 at 2:38 PM José Valim <[email protected]> wrote:
>
>> 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 <[email protected]> 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 <[email protected]> wrote:
>>>
>>> On Tue, 30 Nov 2021 at 12:27, Paul Dann <[email protected]> wrote:
>>>
>>> On Fri, 26 Nov 2021 at 20:22, José Valim <[email protected]> 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 [email protected].
>>> 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 [email protected].
>>> 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 [email protected].
>>> 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/e3991c36-4151-4138-9b99-43cc788bdb3en%40googlegroups.com.
