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 <jose.va...@dashbit.co> 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 <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/CAGnRm4LJ0VdM-s%3Do2WuU1UoNH9%3DQFjsZ9zE6yKdCzL709WtZvQ%40mail.gmail.com.
