Integration Tests
Integration tests in conda
test the application from a high level where each test can
potentially cover large portions of the code. These tests may also use the local
file system and/or perform network calls. In the following sections, we cover
several examples of exactly how these tests look. When writing your own integration tests,
these should serve as a good starting point.
conda_cli
Fixture: Running CLI level tests
CLI level tests are the highest level integration tests you can write. This means that the
code in the test is executed as if you were running it from the command line. For example,
you may want to write a test to confirm that an environment is created after successfully
running conda create
. A test like this would look like the following:
1import json
2from pathlib import Path
3
4from conda.testing.integration import CondaCLIFixture
5
6
7def test_conda_create(conda_cli: CondaCLIFixture, tmp_path: Path):
8 # setup, create environment
9 out, err, code = conda_cli("create", "--prefix", tmp_path, "--yes")
10
11 assert f"conda activate {tmp_path}" in out
12 assert not err # no errors
13 assert not code # success!
14
15 # verify everything worked using the `conda env list` command
16 out, err, code = conda_cli("env", "list", "--json")
17
18 assert any(
19 tmp_path.samefile(path)
20 for path in json.loads(out).get("envs", [])
21 )
22 assert not err # no errors
23 assert not code # success!
24
25 # cleanup, remove environment
26 out, err, code = conda_cli("remove", "--all", "--prefix", tmp_path)
27
28 assert out
29 assert not err # no errors
30 assert not code # success!
Let’s break down exactly what is going on in the code snippet above:
First, we rely on a fixture (conda_cli
) that allows us to run a command using the
current running process. This is much more efficient and quicker than running CLI tests
via subprocesses.
In the test itself, we first create a new environment by effectively running
conda create
. This function returns the standard out, standard error, and the exit
code of the command. This allows us to perform our inspections in order to determine
whether the command ran successfully.
The second part of the test again uses the conda_cli
fixture to call conda env list
.
This time, we pass the --json
flag, which allows capturing JSON that we can better
parse and more easily inspect. We then assert whether the environment we just created is
actually in the list of environments available.
Finally, we destroy the environment we just created and ensure the standard error and the exit code are what we expect them to be.
Warning
It is preferred to use temporary directories (e.g., tmp_path
) whenever possible for
automatic cleanup after tests are run. Otherwise, remember to remove anything created
during the test since it will be present when other tests are run and may result in
unexpected race conditions.
tmp_env
Fixture: Creating a temporary environment
The tmp_env
fixture is a convenient way to create a temporary environment for use in
tests:
1from conda.testing.integration import CondaCLIFixture, TmpEnvFixture
2
3
4def test_environment_with_numpy(
5 tmp_env: TmpEnvFixture,
6 conda_cli: CondaCLIFixture,
7):
8 with tmp_env("numpy") as prefix:
9 out, err, code = conda_cli("list", "--prefix", prefix)
10
11 assert out
12 assert not err # no error
13 assert not code # success!
path_factory
Fixture: Creating a unique (non-existing) path
The path_factory
fixture extends pytest’s tmp_path fixture to provide unique, unused
paths. This makes it easier to generate new paths in tests:
1from conda.testing.integration import (
2 CondaCLIFixture,
3 PathFactoryFixture,
4 TmpEnvFixture,
5)
6
7
8def test_conda_rename(
9 path_factory: PathFactoryFixture,
10 tmp_env: TmpEnvFixture,
11 conda_cli: CondaCLIFixture,
12 tmp_path: Path,
13):
14 # each call to `path_factory` returns a unique path
15 assert path_factory() != path_factory()
16
17 # each call to `path_factory` returns a path that is a child of `tmp_path`
18 assert path_factory().parent == path_factory().parent == tmp_path
19
20 with tmp_env() as prefix:
21 out, err, code = conda_cli("rename", "--prefix", prefix, path_factory())
22
23 assert out
24 assert not err # no error
25 assert not code # success!
Tests with fixtures
Sometimes in integration tests, you may want to re-use the same type of environment more than once. Copying and pasting this setup and teardown code into each individual test can make these tests more difficult to read and harder to maintain.
To overcome this, conda
tests make extensive use of pytest
fixtures. Below is an
example of the previously-shown test, except that we now make the focus of the test the
conda env list
command and move the creation and removal of the environment into a
fixture:
1import json
2from pathlib import Path
3
4from conda.testing.integration import CondaCLIFixture
5
6
7@pytest.fixture
8def env_one(tmp_env: TmpEnvFixture) -> Path:
9 with tmp_env() as prefix:
10 yield prefix
11
12
13def test_conda_create(env_one: Path, conda_cli: CondaCLIFixture):
14 # verify everything worked using the `conda env list` command
15 out, err, code = conda_cli("env", "list", "--json")
16
17 assert any(
18 env_one.samefile(path)
19 for path in json.loads(out).get("envs", [])
20 )
21 assert not err # no errors
22 assert not code # success!
In the fixture named env_one
, we create a new environment using the tmp_env
fixture.
We yield to mark the end of the setup. Since the tmp_env
fixture extends tmp_path
no
additional teardown is needed.
This fixture will be run using the default scope in pytest
, which is function
. This
means that the setup and teardown will occur before and after each test that requests this
fixture. If you need to share an environment or other pieces of data between tests, just
remember to set the fixture scope appropriately. Read here for more
information on pytest
fixture scopes.