What is the recommended approach for testing custom operators outside an Airflow code base?

[tuzonghua]

If I'm building and distributing an internal Airflow provider, for example, a repository that only contains custom operators, hooks, etc., but no DAGs, what is the best way to write integration tests for that code? Official Airflow providers often use the dag_maker fixture as a convenient way to write unit tests (example) that create an in-memory DAG. However, the official documentation suggests dag.test(), which requires a separate DAG file to exist in a configured DAG bundle. If the latter is the answer, will official Airflow providers be migrating to that approach as well?

[keemgdeok]

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 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 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.