sorry, early posted. Not weighing in on the intent here, but the mechanism:
It probably makes sense to leverage the existing tagging/filtering mechanism here. We could then just configure ExUnit like: use ExUnit.Case, independent: [:db_case1, :db_case2] Then treat non-flagged tests as one run, then each independent case as another... But then using tagging, without adding to ExUnit, you could just use filters at the CLI level and run separate suites in sequence at the CI level. ex: mix test --exclude db_case1:true --exclude db_case2:true mix test --include db_case1:true mix test --include db_case2:true Would this approach solve what you are trying to do? On Tuesday, November 30, 2021 at 11:43:48 AM UTC-5 Christopher Keele wrote: > 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/a215af1e-459d-4b70-9198-b3cf8fc960e7n%40googlegroups.com.
