Elixir introduces into the world of programming, the "multiverse testing" pattern. This is a pattern where integration tests are run concurrently and each test sees a shard of global state.

Pre-Existing Examples:

• Mox: each test has access to the global module mock, sharded by the pid of the running test.
• Ecto: each test has access to a "database sandbox", which is a checked out transaction on the global database that acts as its own database shard.
• Hound,Wallaby: each test generates an ID that is passed outside of the BEAM that is reintercepted on ingress, this ID is then used to connect ecto sandboxes to the parent test PID

This library implements Multiverses-aware versions of several constructs in the Elixir Standard Library which aren't natively Multiversable.

For plugins that are provided for other systems, see the libraries:

• :multiverses_finch - which extends this to HTTP requests that exit the BEAM.
• :multiverses_pubsub - which extends this to Phoenix.PubSub

Usage

In mix.exs, you should add the following directive:

{:multiverses, "~> 0.7.0", runtime: (Mix.env() == :test)}}

In your module where you'll be using at least one multiverse module, use the following header:

use Multiverses, with: Registry

this aliases Multiverses.Registry to Registry. As an escape hatch, if you must use the underlying module, you may use the macro alias Elixir.Registry

If you need more complex choices for when to activate Multiverses (such as system environment variables), you should encode those choices directly using logic around the use Multiverses statement.

Options

• :with the names of multiverse modules you'd like to use. May be a single module or a list of modules. Is identical to require Multiverses.<module>; alias Multiverses.<module>.
• :otp_app the otp_app must have its :use_multiverses application environment variable set in order to be used. Defaults to autodetecting via Mix.