Testing Strategy and Setup

The testing strategy for the airflow-ext project focuses on ensuring compatibility across multiple Python versions and Airflow releases (specifically Airflow 2.x and 3.x). The suite validates the core functionality of the extension, with a particular emphasis on the dynamic generation of Airflow Directed Acyclic Graphs (DAGs) from Meltano schedules.

Testing is automated using tox and pytest, utilizing a matrix-based approach to verify that the extension behaves correctly when interacting with different versions of the Apache Airflow orchestrator.

Sources: tox.toml:1-12, pyproject.toml:40-55

Multi-Version Test Matrix

The project employs a comprehensive test matrix managed by tox. This ensures the extension maintains stability across supported environments. The matrix covers Python versions 3.10 through 3.14 and differentiates between Airflow 2.9.x and the upcoming Airflow 3.x series.

Sources: tox.toml:3-12, tox.toml:20-21

The following diagram illustrates the environment orchestration handled by tox:

The diagram shows how tox combines Python versions with Airflow version factors to create isolated test environments.
Sources: tox.toml:3-12

Test Infrastructure and Fixtures

The test infrastructure relies on pytest fixtures to simulate a Meltano project environment without requiring a full Meltano installation during unit tests.

Meltano Project Stubbing

A critical fixture is meltano_project, which stubs the meltano executable. It creates a temporary directory structure and a mock meltano script that mimics the output of meltano schedule list --format=json. This allows tests to inject various schedule payloads (V1 or V2 formats) to verify how the DAG generator processes them.

Sources: tests/conftest.py:38-60

Environment Configuration

The testing setup modifies environment variables to isolate tests from the host system:

• AIRFLOW_HOME: Set to a temporary directory for each test run.
• MELTANO_PROJECT_ROOT: Set to a temporary project directory.
• PATH: Updated to include the directory containing the stubbed meltano binary.

Sources: tests/conftest.py:43-47, tox.toml:23

DAG Generation Validation

The primary focus of the test suite is validating airflow_ext/files/orchestrate/meltano.py, which is the script responsible for generating Airflow DAGs from Meltano schedules.

Testing Logic Flow

Tests use the DagBag class from Airflow to process the generated files without executing them. The validation checks for:

1. Import Errors: Ensuring the generated code is syntactically correct and compatible with the current Airflow version.
2. DAG Existence: Verifying that a DAG is created for each valid schedule.
3. Task Structure: Checking that DAGs contain the expected BashOperator tasks (e.g., extract_load for ELT schedules).
4. Scheduling Constraints: Confirming that "@once" schedules are correctly ignored and do not produce DAGs.

Sources: tests/test_dag_generator.py:53-118

This diagram represents the flow of a single test case validating the dynamic DAG generation logic.
Sources: tests/test_dag_generator.py:53-118, airflow_ext/files/orchestrate/meltano.py:159-178

Schedule Formats Tested

The test suite explicitly handles two versions of Meltano schedule outputs:

• V1: A list of schedule dictionaries.
• V2: A dictionary containing elt and job keys.

Sources: tests/test_dag_generator.py:13-50

Configuration and Warnings

The test runner is configured to be strict regarding warnings. In pyproject.toml, all warnings are filtered to be treated as errors. However, specifically for Airflow 2.x environments, RemovedInAirflow3Warning is configured to appear once to assist in migration debugging without failing the suite immediately if expected.

Sources: pyproject.toml:44-46, tests/conftest.py:33-35

Conclusion

The testing strategy ensures that the meltano-airflow-ext remains a reliable bridge between Meltano and Airflow. By combining strict version-matrix testing with environment stubbing, the project guarantees that DAG generation remains accurate across the evolving Airflow ecosystem, from legacy 2.x deployments to modern 3.x architectures.