View Source Testcontainers.Ecto (testcontainers v1.11.6)
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
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:appoption 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.:check_image(optional) - Defines a custom regular expression that is used to validate the Docker image.
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
endReturns
:okif the container is initiated successfully.{:error, reason}if there is a failure in initiating the container, withreasonexplaining the cause of the failure.
Errors
- Raises
ArgumentErrorif the application is missing, not an atom, or not loaded. - Raises
ArgumentErrorif the repo is defined and not an atom - Raises
ArgumentErrorif 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 Mysql Docker image to maintain consistent and reliable testing conditions.
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:appoption 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.:check_image(optional) - Defines a custom regular expression that is used to validate the Docker image.
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
endReturns
:okif the container is initiated successfully.{:error, reason}if there is a failure in initiating the container, withreasonexplaining the cause of the failure.
Errors
- Raises
ArgumentErrorif the application is missing, not an atom, or not loaded. - Raises
ArgumentErrorif the repo is defined and not an atom - Raises
ArgumentErrorif 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.