ExUnit.Case — ExUnit v1.16.3

Search documentation of ExUnit

# View Source ExUnit.Case (ExUnit v1.16.3)

Helpers for defining test cases.

This module must be used in other modules as a way to configure and prepare them for testing.

When used, it accepts the following options:

- `:async` - configures tests in this module to run concurrently with tests in other modules. Tests in the same module never run concurrently. It should be enabled only if tests do not change any global state. Defaults to `false`.

- `:register` - when `false`, does not register this module within ExUnit server. This means the module won't run when ExUnit suite runs.

> #### `use ExUnit.Case`

> When you `use ExUnit.Case`, it will import the functionality from `ExUnit.Assertions`, `ExUnit.Callbacks`, `ExUnit.DocTest`, and this module itself.

## Examples

    defmodule AssertionTest do
      # Use the module
      use ExUnit.Case, async: true

      # The "test" macro is imported by ExUnit.Case
      test "always pass" do
        assert true
      end
    end

## Context

All tests receive a context as an argument. The context is particularly useful for sharing information between callbacks and tests:

    defmodule KVTest do
      use ExUnit.Case

      setup do
        {:ok, pid} = KV.start_link()
        {:ok, pid: pid}
      end

      test "stores key-value pairs", context do
        assert KV.put(context[:pid], :hello, :world) == :ok
        assert KV.get(context[:pid], :hello) == :world
      end
    end

As the context is a map, it can be pattern matched on to extract information:

    test "stores key-value pairs", %{pid: pid} = _context do
      assert KV.put(pid, :hello, :world) == :ok
      assert KV.get(pid, :hello) == :world
    end

## Tags

The context is used to pass information from the callbacks to the test. In order to pass information from the test to the callback, ExUnit provides tags.

By tagging a test, the tag value can be accessed in the context, allowing the developer to customize the test. Let's see an example:

    defmodule FileTest do
      # Changing directory cannot be async
      use ExUnit.Case, async: false

      setup context do
        # Read the :cd tag value
        if cd = context[:cd] do
          prev_cd = File.cwd!()
          File.cd!(cd)
          on_exit(fn -> File.cd!(prev_cd) end)
        end

        :ok
      end

      @tag cd: "fixtures"
      test "reads UTF-8 fixtures" do
        File.read("README.md")
      end
    end

In the example above, we have defined a tag called `:cd` that is read in the setup callback to configure the working directory the test is going to run on.

Tags are also very effective when used with case templates (`ExUnit.CaseTemplate`) allowing callbacks in the case template to customize the test behaviour.

Note a tag can be set in two different ways:

    @tag key: value
    @tag :key       # equivalent to setting @tag key: true

If a tag is given more than once, the last value wins.

### Module and describe tags

A tag can be set for all tests in a module or describe block by setting `@moduletag` or `@describetag` inside each context respectively:

    defmodule ApiTest do
      use ExUnit.Case
      @moduletag :external

      describe "makes calls to the right endpoint" do
        @describetag :endpoint

        # ...
      end
    end

If you are setting a `@moduletag` or `@describetag` attribute, you must set them after your call to `use ExUnit.Case` otherwise you will see compilation errors.

If the same key is set via `@tag`, the `@tag` value has higher precedence.

The `setup_all` blocks only receive tags that are set using `@moduletag`.

### Known tags

The following tags are set automatically by ExUnit and are therefore reserved:

- `:module` - the module on which the test was defined

- `:file` - the file on which the test was defined

- `:line` - the line on which the test was defined

- `:test` - the test name

- `:async` - if the test case is in async mode

- `:registered` - used for `ExUnit.Case.register_attribute/3` values

- `:describe` - the describe block the test belongs to

- `:describe_line` - the line the describe block begins on

- `:doctest` - the module or the file being doctested (if a doctest)

- `:doctest_line` - the line the doctest was defined (if a doctest)

- `:doctest_data` - additional metadata about doctests (if a doctest)

- `:test_type` - the test type used when printing test results. It is set by ExUnit to `:test`, `:doctest` and so on, but is customizable.

The following tags customize how tests behave:

- `:capture_log` - see the "Log Capture" section below

- `:skip` - skips the test with the given reason

- `:timeout` - customizes the test timeout in milliseconds (defaults to 60000). Accepts `:infinity` as a timeout value.

- `:tmp_dir` - (since v1.11.0) see the "Tmp Dir" section below

## Filters

Tags can also be used to identify specific tests, which can then be included or excluded using filters. The most common functionality is to exclude some particular tests from running, which can be done via `ExUnit.configure/1`:

    # Exclude all external tests from running
    ExUnit.configure(exclude: [external: true])

From now on, ExUnit will not run any test that has the `:external` option set to `true`. This behaviour can be reversed with the `:include` option which is usually passed through the command line:

    $ mix test --include external:true

Run `mix help test` for more information on how to run filters via Mix.

Another use case for tags and filters is to exclude all tests that have a particular tag by default, regardless of its value, and include only a certain subset:

    ExUnit.configure(exclude: :os, include: [os: :unix])

A given include/exclude filter can be given more than once:

    ExUnit.configure(exclude: [os: :unix, os: :windows])

Keep in mind that all tests are included by default, so unless they are excluded first, the `include` option has no effect.

## Log Capture

ExUnit can optionally suppress printing of log messages that are generated during a test. Log messages generated while running a test are captured and only if the test fails are they printed to aid with debugging.

You can opt into this behaviour for individual tests by tagging them with `:capture_log` or enable log capture for all tests in the ExUnit configuration:

    ExUnit.start(capture_log: true)

This default can be overridden by `@tag capture_log: false` or `@moduletag capture_log: false`.

Since `setup_all` blocks don't belong to a specific test, log messages generated in them (or between tests) are never captured. If you want to suppress these messages as well, remove the console backend globally by setting:

    config :logger, backends: []

## Tmp Dir

ExUnit automatically creates a temporary directory for tests tagged with `:tmp_dir` and puts the path to that directory into the test context. The directory is removed before being created to ensure we start with a blank slate.

The temporary directory path is unique (includes the test module and test name) and thus appropriate for running tests concurrently. You can customize the path further by setting the tag to a string, e.g.: `tmp_dir: "my_path"`, which would make the final path to be: `tmp/<module>/<test>/my_path`.

Example:

    defmodule MyTest do
      use ExUnit.Case, async: true

      @tag :tmp_dir
      test "with tmp_dir", %{tmp_dir: tmp_dir} do
        assert tmp_dir =~ "with tmp_dir"
        assert File.dir?(tmp_dir)
      end
    end

As with other tags, `:tmp_dir` can also be set as `@moduletag` and `@describetag`.

# Summary

## Types

env()

## Functions

describe(message, list)

Describes tests together.

get_last_registered_test(mod)

Returns the most recently registered test case as an `%ExUnit.Test{}` struct.

register_attribute(env, name, opts \\ [])

Registers a new attribute to be used during `ExUnit.Case` tests.

register_describe_attribute(env, name, opts \\ [])

Registers a new describe attribute to be used during `ExUnit.Case` tests.

register_module_attribute(env, name, opts \\ [])

Registers a new module attribute to be used during `ExUnit.Case` tests.

register_test(map, test_type, name, tags) deprecated

Registers a test with the given environment.

register_test(mod, file, line, test_type, name, tags)

Registers a function to run as part of this case.

test(message)

Defines a not implemented test with a string.

test(message, var \\ quote do _ end, contents)

Defines a test with `message`.

# Types

Link to this type

# env()

View Source

    @type env() :: module() | Macro.Env.t()

# Functions

Link to this macro

# describe(message, list)

View Source (since 1.3.0) (macro)

Describes tests together.

Every describe block receives a name which is used as prefix for upcoming tests. Inside a block, `ExUnit.Callbacks.setup/1` may be invoked and it will define a setup callback to run only for the current block. The describe name is also added as a tag, allowing developers to run tests for specific blocks.

## Examples

    defmodule StringTest do
      use ExUnit.Case, async: true

      describe "String.downcase/1" do
        test "with ascii characters" do
          assert String.downcase("HELLO") == "hello"
        end

        test "with Unicode" do
          assert String.downcase("HÉLLÒ") == "héllò"
        end
      end
    end

When using Mix, you can run all tests in a describe block by name:

    $ mix test --only describe:"String.downcase/1"

or by passing the exact line the describe block starts on:

    $ mix test path/to/file:123

Note describe blocks cannot be nested. Instead of relying on hierarchy for composition, developers should build on top of named setups. For example:

    defmodule UserManagementTest do
      use ExUnit.Case, async: true

      describe "when user is logged in and is an admin" do
        setup [:log_user_in, :set_type_to_admin]

        test ...
      end

      describe "when user is logged in and is a manager" do
        setup [:log_user_in, :set_type_to_manager]

        test ...
      end

      defp log_user_in(context) do
        # ...
      end
    end

By forbidding hierarchies in favor of named setups, it is straightforward for the developer to glance at each describe block and know exactly the setup steps involved.

Link to this function

# get_last_registered_test(mod)

View Source (since 1.15.0)

    @spec get_last_registered_test(env()) :: ExUnit.Test.t() | nil

Returns the most recently registered test case as an `%ExUnit.Test{}` struct.

This is used by third-party utilities to allow compile-time configuration using test tags without having to explicitly pass the test context at run-time. It is intended to be invoked in macros before the test module is compiled.

Raises if called with a module that has already been compiled.

Link to this function

# register_attribute(env, name, opts \\ [])

View Source (since 1.3.0)

    @spec register_attribute(env(), atom(), keyword()) :: :ok

Registers a new attribute to be used during `ExUnit.Case` tests.

The attribute values will be available through `context.registered`. Registered values are cleared after each `test/3` similar to `@tag`.

This function takes the same options as `Module.register_attribute/3`.

## Examples

    defmodule MyTest do
      use ExUnit.Case

      ExUnit.Case.register_attribute(__MODULE__, :fixtures, accumulate: true)

      @fixtures :user
      @fixtures {:post, insert: false}
      test "using custom attribute", context do
        assert context.registered.fixtures == [{:post, insert: false}, :user]
      end

      test "custom attributes are cleared per test", context do
        assert context.registered.fixtures == []
      end
    end

Link to this function

# register_describe_attribute(env, name, opts \\ [])

View Source (since 1.10.0)

    @spec register_describe_attribute(env(), atom(), keyword()) :: :ok

Registers a new describe attribute to be used during `ExUnit.Case` tests.

The attribute values will be available through `context.registered`. Registered values are cleared after each `describe/2` similar to `@describetag`.

This function takes the same options as `Module.register_attribute/3`.

## Examples

    defmodule MyTest do
      use ExUnit.Case

      ExUnit.Case.register_describe_attribute(__MODULE__, :describe_fixtures, accumulate: true)

      describe "using custom attribute" do
        @describe_fixtures :user
        @describe_fixtures {:post, insert: false}

        test "has attribute", context do
          assert context.registered.describe_fixtures == [{:post, insert: false}, :user]
        end
      end

      describe "custom attributes are cleared per describe" do
        test "doesn't have attributes", context do
          assert context.registered.describe_fixtures == []
        end
      end
    end

Link to this function

# register_module_attribute(env, name, opts \\ [])

View Source (since 1.10.0)

    @spec register_module_attribute(env(), atom(), keyword()) :: :ok

Registers a new module attribute to be used during `ExUnit.Case` tests.

The attribute values will be available through `context.registered`.

This function takes the same options as `Module.register_attribute/3`.

## Examples

    defmodule MyTest do
      use ExUnit.Case

      ExUnit.Case.register_module_attribute(__MODULE__, :module_fixtures, accumulate: true)

      @module_fixtures :user
      @module_fixtures {:post, insert: false}

      test "using custom attribute", context do
        assert context.registered.module_fixtures == [{:post, insert: false}, :user]
      end

      test "still using custom attribute", context do
        assert context.registered.module_fixtures == [{:post, insert: false}, :user]
      end
    end

Link to this function

# register_test(map, test_type, name, tags)

View Source (since 1.3.0)
This function is deprecated. Use register_test/6 instead.

Registers a test with the given environment.

This function is deprecated in favor of `register_test/6` which performs better under tight loops by avoiding `__ENV__`.

Link to this function

# register_test(mod, file, line, test_type, name, tags)

View Source (since 1.10.0)

Registers a function to run as part of this case.

This is used by third-party projects, like QuickCheck, to implement macros like `property/3` that works like `test` but instead defines a property. See `test/3` implementation for an example of invoking this function.

The test type will be converted to a string and pluralized for display. You can use `ExUnit.plural_rule/2` to set a custom pluralization.

Link to this macro

# test(message)

View Source (macro)

Defines a not implemented test with a string.

Provides a convenient macro that allows a test to be defined with a string, but not yet implemented. The resulting test will always fail and print a "Not implemented" error message. The resulting test case is also tagged with `:not_implemented`.

## Examples

    test "this will be a test in future"

Link to this macro

# test(message, var \\ quote do _ end, contents)

View Source (macro)

Defines a test with `message`.

The test may also define a pattern, which will be matched against the test context. For more information on contexts, see `ExUnit.Callbacks`.

## Examples

    test "true is equal to true" do
      assert true == true
    end