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.

Reply via email to