Mox-checkout/Ecto-sandbox style sharding for Application and Registry modules. Allows you to have isolated state so that each test “shards” the respective module and thereafter can only see changes made to the application env or registry pool that come from that test.
If you have runtime Application values, this could be a good way to test that a change to the value has the expected effect, in an async test.
Ok, it is a language thing then? When I hear someone say “the money should be in your account”, I take that as they think the money is there but there is every chance that it isn’t, e.g. they typed the account number incorrectly. So when I read “you should have segregated application values” I wonder in what instance would I not?