# Testing Anaconda — Anaconda 25.14 documentation

# Testing Anaconda

Before testing Anaconda you need to install all required dependencies, prepare the environment and build the sources:

    make -f Makefile.am install-test-requires
    ./autogen.sh
    ./configure
    make

Executing the tests can be done with:

    make check

To run a single test do:

    make TESTS=install/run_install_test.sh check

See tests/Makefile.am for possible values. Alternatively you can try:

    make ci

This has the advantage of producing Python test coverage for all tests. In case the ci target fails there is also a coverage-report target which can be used to combine the multiple .coverage files into one and produce a human readable report.

Note

When using the `ci’ target you need to use a regular user account which is a member of the `mock’ group. You can update your account by running the command:

    # usermod -a -G mock <username>

Your regular user account also needs to execute `sudo’ because some tests require root privileges!

## Test Suite Architecture

Anaconda has a complex test suite structure where each top-level directory represents a different class of tests. They are

- cppcheck/ - static C/C++ code analysis using the cppcheck tool;
- dd_tests/ - Python unit tests for driver disk utilities (utils/dd);
- dracut_tests/ - Python unit tests for the dracut hooks used to configure the installation environment and load Anaconda;
- gettext/ - sanity tests of files used for translation; Written in Python and Bash;
- glade/ - sanity tests for .glade files. Written in Python;
- gui/ - specialized test suite for the graphical interface of anaconda. This is written in Python and uses the dogtail accessibility module. All tests are executed using ./anaconda.py from the local directory;
- install/ - basic RPM sanity test. Checks if anaconda.rpm can be installed in a temporary directory without failing dependencies or other RPM issues;
- lib/ - helper modules used during testing;
- pyanaconda_tests/ - unit tests for the `pyanaconda` module;
- pylint/ - checks the validity of Python source code using the pocketlint tool;
- regex_tests/ - Python unit tests for regular expressions defined in `pyanaconda.regexes`;
- storage/ - test cases used to verify partitioning scenarios for success or expected failures. The scenarios are described using kickstart snippets. Written in Python with a custom test case framework based on blivet;

Note

All Python unit tests inherit from the standard `unittest.TestCase` class unless specified otherwise!

Some tests require root privileges and will be skipped if running as regular user!