Files
pi-hole/test
Adam Warner e1c38e10a7 Replace pytest/tox test suite with BATS
The Python-based test infrastructure (pytest, tox, testinfra) is replaced
with BATS (Bash Automated Testing System), matching the approach already
used in FTL

Changes:
- Add test/run.sh — single entry point replacing all 15 tox.*.ini files;
  accepts DISTRO env var, builds the test image, installs BATS on demand,
  and selects test files based on distro family (debian/alpine/rhel)
- Add test/helpers/mocks.bash — bash equivalents of conftest.py's
  mock_command*, mock_command_2, and mock_command_passthrough helpers;
  uses base64 transfer to write mock scripts into containers safely
- Add test/test_automated_install.bats — replaces test_any_automated_install.py
- Add test/test_utils.bats — replaces test_any_utils.py
- Add test/test_selinux.bats — replaces test_centos_fedora_common_support.py;
  only run on CentOS/Fedora (rhel family)
- Remove conftest.py, requirements.txt, setup.py, __init__.py
- Remove all 15 tox.*.ini files
- Remove all three Python test files
- Update .github/workflows/test.yml: drop Python setup, tox invocation,
  and black formatting check; distro-test job now runs bash test/run.sh
- Update .gitignore: remove Python-specific entries, add test/libs/

Signed-off-by: PromoFaux <PromoFaux@users.noreply.github.com>
Signed-off-by: Adam Warner <me@adamwarner.co.uk>
2026-03-17 18:54:47 +00:00
..
2025-08-16 21:47:54 +00:00
2025-08-16 21:47:54 +00:00
2026-03-17 18:54:47 +00:00

Recommended way to run tests

Make sure you have Docker and Python w/pip package manager.

From command line all you need to do is:

  • pip install tox
  • tox

Tox handles setting up a virtual environment for python dependencies, installing dependencies, building the docker images used by tests, and finally running tests. It's an easy way to have travis-ci like build behavior locally.

Alternative py.test method of running tests

You're responsible for setting up your virtual env and dependencies in this situation.

py.test -vv -n auto -m "build_stage"
py.test -vv -n auto -m "not build_stage"

The build_stage tests have to run first to create the docker images, followed by the actual tests which utilize said images. Unless you're changing your dockerfiles you shouldn't have to run the build_stage every time - but it's a good idea to rebuild at least once a day in case the base Docker images or packages change.

How do I debug python?

Highly recommended: Setup PyCharm on a Docker enabled machine. Having a python debugger like PyCharm changes your life if you've never used it :)