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.
