Files
scheduler/tests
jpmschweitzerandClaude b62024b21d fix(executors): run backups off the event loop
The scheduler serves its own REST API from the same loop that runs executors,
and the config backup spends ~21 minutes inside tarfile and zlib. Called inline
that starves the loop for the whole window: the service was unreachable
03:05-03:25 every night, and again at 07:39 today when the job was triggered by
hand to prove the T-69 report path. asyncio.to_thread is the fix -- zlib
releases the GIL while compressing, so the loop is scheduled normally.

The outage was invisible for as long as it existed. The hourly health check
fires at :35 and the outage runs 03:05-03:25, so no sample ever landed inside
it. A fixed-phase hourly probe cannot see a 20-minute event; that is aliasing,
not bad luck, and it would have stayed hidden indefinitely.

health_report.report_async joins it: psycopg2 is a blocking driver, so
reporting from the loop held it for the connect and insert -- up to
connect_timeout seconds precisely when the database is unreachable, which is
when a report matters most. Both backup executors use it now.

Caveat worth knowing: the engine wraps executors in asyncio.wait_for and a
thread cannot be cancelled, so on timeout the task is recorded failed while the
tar runs to completion. Still strictly better than blocking everything, and the
configured 3600s is well clear of the observed 1263s.

Seven tests in this file had been red since the initial commit -- they came
over with the portainer-core extraction, patched the Path class wholesale,
asserted "backed up" against a function returning "Backup completed: ...", and
one wrapped its call in except Exception: pass with its only assertion
commented out. There is no CI test gate here, so nothing reported it. Replaced
with tests that build real archives in tmp_path and assert on their contents.

The new loop test is the one that matters and it is mutation-checked: with
to_thread reverted it counts 0 heartbeat ticks, with it ~40.

Their structural demands (_create_tar_filter, a sync _cleanup_old_backups) were
adopted because threading wanted that shape anyway. Their exclude semantics
were not. The tests assert fnmatch behaviour and the deployed config is written
against substring matching -- it excludes logs as ".log", and paths as
unanchored fragments like "ollama/models/*" against members named
"docker-data/ollama/...". Under fnmatch neither matches, and the nightly
archive would silently gain many GB of model blobs instead of shrinking. That
is now pinned by tests naming the consequence, so the "improvement" fails loudly.

Co-Authored-By: Claude <noreply@anthropic.com>
2026-08-11 11:35:29 +02:00
..

Scheduler Tests

Comprehensive test suite for The Scheduler using pytest.

Test Structure

tests/
├── conftest.py                    # Shared fixtures and configuration
├── test_api.py                    # API endpoint tests
├── test_example_executor.py       # Example executor tests
├── test_doc_sync_executor.py      # Documentation sync executor tests
└── README.md                      # This file

Running Tests

Run all tests

docker exec scheduler pytest

Run with coverage report

docker exec scheduler pytest --cov=src --cov-report=term-missing

Run specific test file

docker exec scheduler pytest tests/test_api.py

Run specific test class

docker exec scheduler pytest tests/test_api.py::TestHealthEndpoint

Run specific test

docker exec scheduler pytest tests/test_api.py::TestHealthEndpoint::test_health_endpoint_returns_healthy

Run tests by marker

# Run only unit tests
docker exec scheduler pytest -m unit

# Run only API tests
docker exec scheduler pytest -m api

# Run only executor tests
docker exec scheduler pytest -m executor

# Run only fast tests (exclude slow)
docker exec scheduler pytest -m "not slow"

Run with verbose output

docker exec scheduler pytest -v

Run with detailed failure output

docker exec scheduler pytest -vv --tb=long

Stop on first failure

docker exec scheduler pytest -x

Test Markers

Tests are organized with pytest markers:

  • @pytest.mark.unit - Fast unit tests with no external dependencies
  • @pytest.mark.integration - Integration tests (may use database)
  • @pytest.mark.api - API endpoint tests
  • @pytest.mark.executor - Task executor tests
  • @pytest.mark.slow - Tests that take a while to run

Coverage Reports

After running tests with coverage:

  • Terminal: Shows missing lines in terminal output
  • HTML: Open htmlcov/index.html in browser for detailed report
  • JSON: Machine-readable coverage data in coverage.json

View HTML coverage report:

# From host machine
open /home/jpmschweitzer/docker-data/scheduler/htmlcov/index.html

Writing New Tests

Test File Naming

  • Test files must start with test_
  • Place in tests/ directory
  • Use descriptive names: test_<module_name>.py

Test Function Naming

  • Test functions must start with test_
  • Use descriptive names: test_<what_is_being_tested>

Using Fixtures

Fixtures are defined in conftest.py:

def test_something(test_settings, auth_headers):
    # Use fixtures as function parameters
    assert test_settings.app_name == "Test Scheduler"

Adding Markers

@pytest.mark.unit
@pytest.mark.api
def test_health_endpoint(client):
    response = client.get("/health")
    assert response.status_code == 200

Async Tests

@pytest.mark.asyncio
async def test_async_function():
    result = await some_async_function()
    assert result is not None

Mocking

from unittest.mock import patch, MagicMock

def test_with_mock():
    with patch('module.function') as mock_func:
        mock_func.return_value = "mocked"
        result = call_function_that_uses_it()
        assert result == "mocked"

Continuous Integration

These tests are designed to run in CI pipelines:

# Example GitHub Actions
- name: Run tests
  run: |
    docker exec scheduler pytest --cov=src --cov-report=xml
    docker exec scheduler pytest --cov=src --cov-report=html

Test Database

Tests use mocked database connections by default. For integration tests that require a real database:

  1. Set up a test database
  2. Use POSTGRES_DB=test_scheduler environment variable
  3. Run migrations before tests
  4. Clean up after tests

Troubleshooting

Tests fail with "ModuleNotFoundError"

# Install test dependencies
docker exec scheduler /venv/bin/pip install -r requirements.txt

Tests fail with database errors

  • Tests use mocked connections by default
  • Check that mocks are properly set up in conftest.py
  • For integration tests, ensure test database exists

Coverage not working

# Reinstall pytest-cov
docker exec scheduler /venv/bin/pip install --upgrade pytest-cov

Best Practices

  1. Fast by default: Unit tests should be fast (<1s each)
  2. Isolated: Tests should not depend on each other
  3. Descriptive: Test names should clearly describe what they test
  4. Single assertion: Test one thing per test when possible
  5. Use fixtures: Reuse common setup via fixtures
  6. Mock external deps: Don't hit real databases/APIs in unit tests
  7. Mark appropriately: Use markers to categorize tests

Current Coverage

Run this to see current coverage:

docker exec scheduler pytest --cov=src --cov-report=term

Target: 80%+ code coverage for critical paths