GitHub user Labeeb2339 added a comment to the discussion: What is the recommended approach for testing custom operators outside an Airflow code base?
For an internal provider repository with no production DAGs, I would keep two layers separate: - Use Airflow's `dag_maker` pytest fixture for operator/hook integration tests. It creates an in-memory DAG and gives the test the Airflow context needed to create a DagRun/TaskInstance and exercise the operator, so a throwaway DAG file or configured DAG bundle is not required. - Use `dag.test()` when the thing being tested is an actual DAG file as a whole: task dependencies, templating, and the end-to-end execution flow. It is not a replacement for unit-testing a reusable operator class. A provider test can therefore follow the same shape as the official provider tests: construct the DAG inside the test with `dag_maker`, instantiate the custom operator under that DAG, create/run the task instance using the test fixture, and mock only the external service boundary. Put a small real DAG under a test/example-dags area only when you specifically want to validate DAG parsing or `dag.test()` behavior. For tests that must exercise a real executor, scheduler, or external service, use the provider's system/integration-test setup separately; `dag.test()` defaults to a local simulated run unless `use_executor=True` is supplied. The current docs describe that distinction here: https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/debug.html#testing-dags-with-dag-test GitHub link: https://github.com/apache/airflow/discussions/72120#discussioncomment-18171382 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
