Not weighing in on the intent here, but the mechanism: It probably makes sense to leverage the existing tagging mechanism here. We could then just configure ExUnit like:
use ExUnit.Case On Tuesday, November 30, 2021 at 7:28:09 AM UTC-5 pdgi...@gmail.com wrote: > Sorry for the delay in response! > > On Fri, 26 Nov 2021 at 16:49, Adam Lancaster <ad...@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....@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/a7c72818-2952-425e-a4c5-154747c3c348n%40googlegroups.com.