GitHub user keemgdeok added a comment to the discussion: What is the recommended approach for testing custom operators outside an Airflow code base?
For a standalone provider, I'd keep a small **test-only DAG** for integration tests, even if the distributed package contains no DAGs. Install the provider into an isolated Airflow test environment, put that DAG in a configured test bundle, initialize the test metadata DB, and run it with `dag.test()` or `airflow dags test`. That exercises task execution, templating and XCom through Airflow. The [3.3.2 debugging docs](https://airflow.apache.org/docs/apache-airflow/3.3.2/core-concepts/debug.html#testing-dags-with-dag-test) describe these prerequisites. For operator unit tests, you can stay with pytest: mock the external service, call `execute()` or `poke()` with the context keys your implementation uses, and call `render_template_fields()` separately when needed. The [updated operator testing docs](https://airflow.apache.org/docs/apache-airflow/3.3.2/howto/custom-operator.html#testing-your-operator) now make that distinction. `dag_maker` belongs to Airflow's repository test infrastructure; it also handles database serialization, so it is doing more than constructing an in-memory DAG. I'd avoid importing that internal fixture into an independently distributed provider. I wouldn't read #71542 as a commitment to migrate all upstream provider tests—it clarifies the public testing guidance. GitHub link: https://github.com/apache/airflow/discussions/72120#discussioncomment-18737203 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
