View Source Testcontainers.Ecto (testcontainers v1.7.0)

Facilitates the creation of a Postgres or MySql container for testing with Ecto.

This module simplifies the process of launching a real Postgres or MySql database instance within a Docker container for testing purposes. It leverages the Testcontainers library to instantiate a Postgres or MySql container with the desired configuration, providing an isolated database environment for each test session.

Summary

Functions

Initiates a new Mysql instance, executes migrations, and prepares a suitable database environment, specifically tailored for testing scenarios.

Initiates a new Postgres instance, executes migrations, and prepares a suitable database environment, specifically tailored for testing scenarios.

Functions

Link to this function

mysql_container(options \\ [])

View Source

Initiates a new Mysql instance, executes migrations, and prepares a suitable database environment, specifically tailored for testing scenarios.

Parameters

  • options: Configurations for the Mysql container, provided as a keyword list. The only required option is :app. Other options include:
    • :app - The current application's atom, necessary for building paths and other application-specific logic. This is a required parameter.
    • :repo (optional) - The Ecto repository module for database interaction. If not provided, it is inferred from the :app option using the default naming convention (e.g., MyApp.Repo).
    • :image (optional) - Specifies the Docker image for the Mysql container. This must be a legitimate Mysql image, with the image name beginning with "mysql". If omitted, the default is "mysql:8".
    • :user (optional) - Sets the username for the Mysql instance (defaults to "test").
    • :password (optional) - Determines the password for the Mysql user (defaults to "test").
    • :database (optional) - Specifies the name of the database to be created within the Mysql instance. If not provided, the default behavior is to create a database with the name derived from the application's atom, appended with "_test".
    • :migrations_path (optional) - Indicates the path to the migrations folder (defaults to "priv/repo/migrations").
    • :persistent_volume_name (optional, EXPERIMENTAL) - Sets a named volume for the data in the database. This is an experimental option, and changes in database container image or other things that could invalidate the data, would make the container not start properly.

Database Lifecycle in Testing

It's important to note that the Mysql database initiated by this function will remain operational for the duration of the test process and is not explicitly shut down by the function. The database and its corresponding data are ephemeral, lasting only for the scope of the test session.

After the tests conclude, Testcontainers will clean up by removing the database container, ensuring no residual data persists. This approach helps maintain a clean testing environment and prevents any unintended side effects on subsequent tests due to data leftovers.

Users should not rely on any manual teardown or cleanup for the database, as Testcontainers handles this aspect automatically, providing isolated, repeatable test runs.

Examples

# First, you must change the Ecto adapter from Postgres to MyXQL

defmodule MyApp.Repo do
  use Ecto.Repo,
    otp_app: :my_app,
    adapter: Ecto.Adapters.MyXQL # <- should look like this
end

# Then, in your application.ex file in your Phoenix project:

import Testcontainers.Ecto

@impl true
def start(_type, _args) do
  mysql_container(
    app: :my_app,
    user: "postgres", # consider changing this to something else here and in config/test.exs
    password: "postgres" # consider changing this to something else here and in config/test.exs
  )

  # .. other setup code
end

# Lastly, in mix.exs, modify the aliases to remove default Ecto setup tasks from the test alias,
# as they might interfere with the container-based database setup:

def aliases do
  [
    # ... other aliases

    # Ensure the following line is NOT present, as it would conflict with the container setup:
    # test: ["ecto.create --quiet", "ecto.migrate --quiet", "test"],
  ]
end

# in your config/test.exs, if you want to keep appending the MIX_TEST_PARTITION env variable to the database name,
# you must set the database option in mysql_container function to the same value

config :my_app, MyApp.Repo,
  username: "postgres", # <- consider changing this when using mysql
  password: "postgres", # <- consider changing this when using mysql
  hostname: "localhost",
  database: "my_app_test#{System.get_env("MIX_TEST_PARTITION")}", # set this also in mysql_container function database option, or remove the appending
  pool: Ecto.Adapters.SQL.Sandbox,
  pool_size: 10

# for example, to set the database name to the one above, in application.ex:

@impl true
def start(_type, _args) do
  mysql_container(
    app: :my_app,
    user: "postgres", # <- consider changing this when using mysql
    password: "postgres", # <- consider changing this when using mysql
    database: "my_app_test#{System.get_env("MIX_TEST_PARTITION")}"
  )

  # .. other setup code
end

Returns

  • :ok if the container is initiated successfully.
  • {:error, reason} if there is a failure in initiating the container, with reason explaining the cause of the failure.

Errors

  • Raises ArgumentError if the application is missing, not an atom, or not loaded.
  • Raises ArgumentError if the repo is defined and not an atom
  • Raises ArgumentError if the specified Docker image is not a valid MySql image.

Note

This utility is intended for testing environments requiring a genuine database instance. It is not suitable for production use. It mandates a valid Postgres Docker image to maintain consistent and reliable testing conditions.

Link to this function

postgres_container(options \\ [])

View Source

Initiates a new Postgres instance, executes migrations, and prepares a suitable database environment, specifically tailored for testing scenarios.

Parameters

  • options: Configurations for the Postgres container, provided as a keyword list. The only required option is :app. Other options include:
    • :app - The current application's atom, necessary for building paths and other application-specific logic. This is a required parameter.
    • :repo (optional) - The Ecto repository module for database interaction. If not provided, it is inferred from the :app option using the default naming convention (e.g., MyApp.Repo).
    • :image (optional) - Specifies the Docker image for the Postgres container. This must be a legitimate Postgres image, with the image name beginning with "postgres". If omitted, the default is "postgres:15".
    • :user (optional) - Sets the username for the Postgres instance (defaults to "postgres").
    • :password (optional) - Determines the password for the Postgres user (defaults to "postgres").
    • :database (optional) - Specifies the name of the database to be created within the Postgres instance. If not provided, the default behavior is to create a database with the name derived from the application's atom, appended with "_test".
    • :migrations_path (optional) - Indicates the path to the migrations folder (defaults to "priv/repo/migrations").
    • :persistent_volume_name (optional, EXPERIMENTAL) - Sets a named volume for the data in the database. This is an experimental option, and changes in database container image or other things that could invalidate the data, would make the container not start properly.

Database Lifecycle in Testing

It's important to note that the Postgres database initiated by this function will remain operational for the duration of the test process and is not explicitly shut down by the test. The database and its corresponding data are ephemeral, lasting only for the scope of the test session.

After the tests conclude, Testcontainers will clean up by removing the database container, ensuring no residual data persists. This approach helps maintain a clean testing environment and prevents any unintended side effects on subsequent tests due to data leftovers.

Users should not rely on any manual teardown or cleanup for the database, as Testcontainers handles this aspect automatically, providing isolated, repeatable test runs.

Examples

# In your application.ex file in your Phoenix project:

import Testcontainers.Ecto

@impl true
def start(_type, _args) do
  postgres_container(
    app: :my_app,
    user: "postgres",
    password: "postgres"
  )

  # .. other setup code
end

# In mix.exs, modify the aliases to remove default Ecto setup tasks from the test alias,
# as they might interfere with the container-based database setup:

def aliases do
  [
    # ... other aliases

    # Ensure the following line is NOT present, as it would conflict with the container setup:
    # test: ["ecto.create --quiet", "ecto.migrate --quiet", "test"],
  ]
end

# in your config/test.exs, if you want to keep appending the MIX_TEST_PARTITION env variable to the database name,
# you must set the database option in postgres_container function to the same value

config :my_app, MyApp.Repo,
  username: "postgres",
  password: "postgres",
  hostname: "localhost",
  database: "my_app_test#{System.get_env("MIX_TEST_PARTITION")}", # set this also in postgres_container function database option, or remove the appending
  pool: Ecto.Adapters.SQL.Sandbox,
  pool_size: 10

# for example, to set the database name to the one above, in application.ex:

@impl true
def start(_type, _args) do
  postgres_container(
    app: :my_app,
    user: "postgres",
    password: "postgres",
    database: "my_app_test#{System.get_env("MIX_TEST_PARTITION")}"
  )

  # .. other setup code
end

Returns

  • :ok if the container is initiated successfully.
  • {:error, reason} if there is a failure in initiating the container, with reason explaining the cause of the failure.

Errors

  • Raises ArgumentError if the application is missing, not an atom, or not loaded.
  • Raises ArgumentError if the repo is defined and not an atom
  • Raises ArgumentError if the specified Docker image is not a valid Postgres image.

Note

This utility is intended for testing environments requiring a genuine database instance. It is not suitable for production use. It mandates a valid Postgres Docker image to maintain consistent and reliable testing conditions.