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.
