After many years of not being proud of how I implemented it, now I’m pretty happy with how I’ve structured this library. Presenting Multiverses:
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.
@ityonemo why do the docs say:
Your tests should have segregated appliction values!
It’s a little disconcerting to see “should” in that sentence. Does it not always work?
Application env is shared global state!
Yes of course, but isn’t the point of this library to shard that so tests have an isolated version?
Exactly. You should have isolated application envs, so you should use this library!! Hm. I should make the docs more clear, then.
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?