Hi everyone,

The Task SDK Execution API integration test stub work is complete👏!

Here's a *not so short *summary -

Now we have a total of 39 integration tests across 8 test files:

1. Task Instance Operations (test_task_instance_operations.py): 7 tests
- get_previous_successful_dagrun, validate_inlets_and_outlets, get_count,
get_task_states,
set_rtif, heartbeat, finish (state transitions)

2. XCom Operations (test_xcom_operations.py): 11 tests
- get, get_not_found, set, delete, head (unmapped & mapped),
get_sequence_item (parametrized),
get_sequence_item_not_found (offset & wrong_key), get_sequence_slice
(parametrized),
get_sequence_slice_not_found

3. DAG Run Operations (test_dag_run_operations.py): 6 tests
- get_state, get_state_not_found, get_count, get_count_not_found,
get_previous,
get_previous_not_found

4. Asset Operations (test_asset_operations.py): 4 tests
- get_by_name, get_by_name_not_found, get_by_uri, get_by_uri_not_found

5. Asset Event Operations (test_asset_event_operations.py): 4 tests
- get (by name), get_not_found, get_by_uri, get_by_alias

5. Variable Operations (test_variable_operations.py): 4 tests
- get, get_not_found, set, delete

6. Connection Operations (test_connection_operations.py): 2 tests
- get, get_not_found

7. Health Operations (test_task_sdk_health.py): 1 test
- health check


That is not all, we also made a lot of infrastructure enhancements along
the journey
like:

- Migrated test suite from task-sdk-tests to task-sdk-integration-tests
with hot reload
functionality for quick iteration
- Better organisation with better fixtures
- Early checks and validations for docker and docker compose versions
- Environment configuration: .env file support for docker compose variables
- CI cadence and selective check improvements
- And more...

Thanks to Pratiksha (@Prab-27), Henry Chen (@henry3260), Jake
(@jroachgolf84),
Jeongwoo Do (@wjddn279) for their contributions (sorry if I missed anyone
:))

Thanks to Jarek for help with infra fixes / his guidance and Jason (Zhe You
Liu)
for the hot reload functionality!

I'll reach out in the future for similar tasks. Thanks for the support!

Thanks & Regards,
Amogh Desai


On Fri, Nov 28, 2025 at 12:34 PM Amogh Desai <[email protected]> wrote:

> Hi All,
>
> An update on this one: we added stubs for most missing tests at the time
> but stubs
> for two files were missing and are still up for grabs (once this PR gets
> merged: https://github.com/apache/airflow/pull/58805)
>
> 1. test_asset_event_operations.py
>
> 2. test_asset_event_operations.py
>
> Both stubs are in place with @pytest.mark.skip and docstrings. They follow
> the same pattern as the existing tests. If you want to pick these
> up, leave a comment on: https://github.com/apache/airflow/issues/58178.
>
> These are straightforward additions that follow existing patterns.
>
> Thanks & Regards,
> Amogh Desai
>
>
> On Tue, Nov 11, 2025 at 7:05 PM Srabasti Banerjee <
> [email protected]> wrote:
>
>> Thanks for sharing this @Amogh Desai <[email protected]> !
>>
>> Joined the Slack channel and want to contribute to make changes to the
>> below file for XComs.
>> test_xcom_operations.py - XCom operations
>>
>> Can you please assign the same?
>>
>> Warm Regards,
>> Srabasti Banerjee
>>
>> On Tue, Nov 11, 2025 at 2:44 AM Amogh Desai <[email protected]>
>> wrote:
>>
>>> I wanted to inform you that the Slack channel for
>>> sig-airflow-task-sdk-integration-tests has now been created. This will
>>> make
>>> it easier for us to collaborate and discuss
>>> any questions or clarifications regarding the integration testing
>>> process.
>>>
>>> Looking forward to making progress together!
>>>
>>>
>>> On Tue, Nov 11, 2025 at 10:34 AM Amogh Desai <[email protected]>
>>> wrote:
>>>
>>> > Hello All,
>>> >
>>> > I am reaching out to ask for your help in completing the integration
>>> test
>>> > suite for the Apache Airflow Task SDK Execution API. This is a great
>>> > opportunity to contribute
>>> > to Airflow's testing infrastructure while learning about the Task SDK
>>> and
>>> > Execution API. More details about this on the issue:
>>> > https://github.com/apache/airflow/issues/58178
>>> >
>>> > *Why are we doing this?*
>>> >
>>> > As outlined in our [Task SDK Integration Tests documentation](
>>> >
>>> https://github.com/apache/airflow/blob/main/contributing-docs/testing/task_sdk_integration_tests.rst
>>> > ),
>>> > these integration tests serve several critical purposes:
>>> >
>>> > *1. API Compatibility Assurance*
>>> >   The Task SDK communicates with Airflow through well defined APIs for
>>> > task execution. These tests ensure that changes to either the SDK or
>>> > Airflow core don't break
>>> > the interface contract between the two.
>>> >
>>> > *2. Real World Scenario Testing*
>>> >   While unit tests verify individual components work correctly,
>>> > integration tests validate that the entire system works together as
>>> > expected in deployment scenarios.
>>> >
>>> > *3. Quicker Resolution for Interface Incompatibility*
>>> >   These tests catch integration issues early in the development cycle,
>>> > preventing breaking changes from reaching a release.
>>> >
>>> > *What has been done already:*
>>> >
>>> > We've made significant progress setting up the test infrastructure and
>>> > implementing core tests, more details in the issue:
>>> > https://github.com/apache/airflow/issues/58178
>>> >
>>> > *What needs to be done*
>>> >
>>> > We have **stub test functions** ready for implementation across
>>> multiple
>>> > test files. Each stub includes:
>>> > - Clear docstring describing what to test
>>> > - Expected response type and endpoint information
>>> > - `@pytest.mark.skip` decorator marking it as TODO
>>> > - Placeholder for implementation
>>> >
>>> > This is a great contribution opportunity because it offers a clear and
>>> > structured approach — each test stub comes with detailed documentation
>>> > explaining exactly what needs to
>>> > be tested. You can follow established test patterns without needing to
>>> > design new approaches, making it easy to get started. The work is
>>> > self-contained, meaning each test file
>>> > can be developed independently, allowing contributors to make
>>> meaningful
>>> > progress without dependencies. It’s also a valuable learning
>>> experience,
>>> > providing insight into the
>>> > Task SDK Execution API and how it works in practice. Most importantly,
>>> > these tests have real impact by helping prevent regressions and
>>> ensuring
>>> > long term API compatibility.
>>> >
>>> >
>>> > We're here to help! Don't hesitate to reach out if you have questions
>>> or
>>> > need clarification.
>>> >
>>> > P.S: Will be creating a slack channel for this shortly, as
>>> communicated in
>>> > the GH issue.
>>> >
>>> > Thanks & Regards,
>>> > Amogh Desai
>>> >
>>>
>>

Reply via email to