Sorry for the delay in response! On Fri, 26 Nov 2021 at 16:49, Adam Lancaster <a...@a-corp.co.uk> wrote:
> I think the point is that an exclusion group needs to be managed manually, > which means if you add a new module you have to check every test to see if > the module needs adding to an exclusion group there... which seems worse > than just making the test async: false. > Well, only if you want the new module to run async and are willing to put in a little extra effort to achieve that. There would of course still be the simple option of using async: false. I'd expect that a good naming scheme would help. The situation is not _too_ dissimilar from test tags in that regard - they need to be manually checked for consistency or a test may be incorrectly excluded from CI, for instance. > Worth pointing out (you may or may not know) you can pull your synchronous > tests into their own module so the absolute minimum number of tests are > running async which seems to be what you are after? Also that module can be > in the same test file as a test module with async tests inside them. > A good reminder; thanks. But many of the tests I'm working with at the moment deal with temporary fixture data in a db that doesn't support transactions. Most test files use different tables, though, so running async is generally fine (and desirable, because some tests are long-running), except for one or two that shouldn't be run at the same time as specific other test files because of touching the same tables. 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. 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-VpQotBrqm_qAnW-grXJUZTM9BRa4hYQJmXAuKSWr4r7jg%40mail.gmail.com.
