Testing DAGs & CI/CD Deployment

A DAG file that fails to parse does not fail like a task. No run starts, so no task fails, and task alerts do not fire.

The UI shows an import error, but only to someone who looks. So the most useful tests run before deployment, in layers from cheap to expensive:

Then the chapter shows how DAG code reaches production, and how to check that your change is live.

DagBag reads a folder of DAG files the way Airflow does. One small test file can check every DAG at once:

import pytest
from airflow.models import DagBag


@pytest.fixture(scope="session")
def dagbag():
    return DagBag(dag_folder="dags", include_examples=False)


def test_no_import_errors(dagbag):
    assert dagbag.import_errors == {}


def test_every_dag_has_tags_and_a_timeout(dagbag):
    for dag_id, dag in dagbag.dags.items():
        assert dag.tags, f"{dag_id} has no tags"
        assert dag.dagrun_timeout is not None, f"{dag_id} has no dagrun_timeout"

We added two bad files to the folder. The first test listed both:

Then we added a DAG with no dagrun_timeout. The second test failed with: refresh_dashboard has no dagrun_timeout.

Each rule in this file turns a team habit into a check. Add a rule each time a missing setting causes a problem, such as no owner or no retries.

A task that reads, decides and writes in one function is hard to test. You need a fake database just to check the rule in the middle.

So move each decision into a plain function. Here is the revenue rule, with no Airflow in it:

def paid_revenue(orders):
    return round(sum(o["amount"] for o in orders if o["status"] == "paid"), 2)


def test_only_paid_orders_count():
    assert paid_revenue(ORDERS) == 160.50   # the six shop orders


def test_no_orders_gives_zero():
    assert paid_revenue([]) == 0

The task then only reads the orders, calls paid_revenue and writes the result. Most of the risk is in the rule, and the rule now has fast tests.

You can also test a template without running Airflow. render_template fills it with the values you give:

op = BashOperator(
    task_id="copy",
    bash_command="aws s3 cp orders.csv s3://shop/raw/{{ ds }}/",
)
print(op.render_template(op.bash_command, {"ds": "2026-01-10"}))

CI runs your checks on every change. People only wait for it when it is fast. If it takes ten minutes, they merge without it, and it catches nothing.

So split the checks by cost:

ruff’s AIR rules find Airflow 2 code before an upgrade breaks it. On a small Airflow 2 file, ruff check --select AIR reported:

from datetime import datetime
from airflow import DAG
from airflow.operators.python import PythonOperator

with DAG("old_style", schedule_interval="@daily", start_date=datetime(2026, 1, 1)) as dag:
    PythonOperator(task_id="load", python_callable=lambda: None)

In Airflow 3, DAG files come from a DAG bundle. The default is the local dags folder. You still need a way to put your files there, and teams usually pick one of these:

A baked image is slower, but the code always matches the packages it was tested with. Syncing is fast, but a new DAG can need a package the image does not have yet.

A green CI run does not mean the change is live. Check when Airflow last parsed the DAG:

airflow dags details shop_orders_daily

Fast checks always, and a deploy you can verify:

1. A DAG that fails to parse runs nothing, and no task alert fires. Test parsing before you deploy.
2. One DagBag test checks import errors, cycles and required settings.
3. Move business rules into plain functions, and test them with plain Python.
4. Keep every-commit checks fast. Run slow ones before merge or deploy.
5. After a deploy, check last_parsed_time.

Check yourself: a new DAG never appeared in the UI, and no alert fired. Which test would have caught it? (Answer: the DagBag import errors test.)