add E2E tests for DAG Runs tab

[Sahil-Shadwal]

Add E2E tests for DAG Runs tab functionality.

Changes

• Added data-testid to DagRuns.tsx for E2E testing
• Extended DagsPage.ts with 7 methods for Runs tab interactions
• Created test suite with 4 test cases covering navigation, display, filtering, search, and pagination

Test Coverage

✅ Navigate to Runs tab
✅ Verify run details (ID, state, times, duration)
✅ Click run to view details
✅ Filter and search functionality
✅ Pagination

Closes #59541

Related issues: #59028

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[vatsrahul1001]

Thanks for the PR @Sahil-Shadwal I will review soon

[vatsrahul1001]

@Sahil-Shadwal can you look at failures?

[Sahil-Shadwal]

@Sahil-Shadwal can you look at failures?

On it

[vatsrahul1001]

@Sahil-Shadwal All of dag run tab test failing can you check?

[Sahil-Shadwal]

@Sahil-Shadwal All of dag run tab test failing can you check?
hey @vatsrahul1001
I'm working on stabilizing the E2E tests for the DAG Runs Tab.

Progress so far: I've resolved the major blocking issues preventing the tests from running:

Fixed the this.waitForPageLoad is not a function crash by implementing the correct Playwright wait states.
Added proper authentication (LoginPage flow) which was missing from the spec, causing navigation failures.
Fixed timeout issues caused by aggressive DAG triggering in the beforeEach hook.
Current Issue: While the tests now run and authenticate correctly, I'm seeing failures specifically on [e.g., "verifying run details" or "pagination"]. It appears the tests are unable to locate specific elements on the Runs tab, even though the page loads.

My Ask:

Is there a specific attribute or data-testid convention I should be using for the Runs tab table specifically?
Do we need to seed specific run data in the test environment (e.g., using breeze setup) beyond what the default DAGs provide?
Any pointers would be appreciated!

[vatsrahul1001]

@Sahil-Shadwal Thanks for working on this! A few things to address:

1. Move DAG trigger to beforeAll - Running in beforeEach is too slow (6 triggers for 6 tests). Create runs with different states for proper testing(this will help in filtering tet)
   You can change dag run success state to failed state with patch call

await page.request.patch(
        `/api/v1/dags/${testDagId}/dagRuns/${runId}`,
        { data: { state: "failed" } }

3. Create separate dag-runs.spec.ts - Don't add to dags-list.spec.ts

4. Filter test improvement - Currently filters by a state that already exists. Either create runs with mixed states, or use the API to mark a run as failed to properly test filtering we can do it in before all

5. Pagination - Use ?offset=0&limit=1 URL param to test pagination without needing many runs

6. Search test - Search for a partial pattern and verify fewer results returned

7. Add a test for sorting as well.

8. Verify waitForPageLoad - Make sure it exists in BasePage or use waitForLoadState("networkidle")

9. You need to rebase

Let me know if you have questions!

[vatsrahul1001]

@Sahil-Shadwal All of dag run tab test failing can you check?
hey @vatsrahul1001
I'm working on stabilizing the E2E tests for the DAG Runs Tab.

Progress so far: I've resolved the major blocking issues preventing the tests from running:

Fixed the this.waitForPageLoad is not a function crash by implementing the correct Playwright wait states. Added proper authentication (LoginPage flow) which was missing from the spec, causing navigation failures. Fixed timeout issues caused by aggressive DAG triggering in the beforeEach hook. Current Issue: While the tests now run and authenticate correctly, I'm seeing failures specifically on [e.g., "verifying run details" or "pagination"]. It appears the tests are unable to locate specific elements on the Runs tab, even though the page loads.

My Ask:

Is there a specific attribute or data-testid convention I should be using for the Runs tab table specifically? Do we need to seed specific run data in the test environment (e.g., using breeze setup) beyond what the default DAGs provide? Any pointers would be appreciated!

@Sahil-Shadwal Thanks for the update on your progress!

1. data-testid conventions for Runs tab

The ones you have added in tests looks correct. The issue you're seeing with element location is likely timing - the table loads asynchronously. Make sure you're waiting for the table to be visible before querying rows:

await this.runsTable.waitFor({ state: "visible", timeout: 10_000 });

2. Seeding test data

You don't need to seed data manually. Instead, create the data you need in beforeAll:

test.beforeAll(async ({ browser }) => {
test.setTimeout(5 * 60 * 1000);

const context = await browser.newContext({ storageState: AUTH_FILE });
const page = await context.newPage();
const setupPage = new DagsPage(page);

await setupPage.triggerDag(testDagId);
await setupPage.triggerDag(testDagId);

const response = await page.request.get(
/api/v1/dags/${testDagId}/dagRuns?limit=1
);
const data = await response.json();
const runId = data.dag_runs[0]?.dag_run_id;

if (runId) {
await page.request.patch(
/api/v1/dags/${testDagId}/dagRuns/${runId},
{ data: { state: "failed" } }
);
}

await context.close();
});This creates the test data once before all tests run, and gives you both successful and failed runs for proper filter testing.

3. waitForPageLoad issue

If waitForPageLoad doesn't exist in BasePage, use:
await this.page.waitForLoadState("networkidle");Let me know if you run into other issues!

[Sahil-Shadwal]

[vatsrahul1001]

@Sahil-Shadwal can you resolve conflicts?

[Sahil-Shadwal]

@Sahil-Shadwal can you resolve conflicts?

✅done

[vatsrahul1001]

@Sahil-Shadwal CI is failing can you have a look also I see you are using login in pages we should not do that

[Sahil-Shadwal]

@vatsrahul1001

Hey, thanks for sticking with me on this - I know it's taken way longer than it should have. Really appreciate you taking the time to explain the patterns.

Just pushed a fix removing the LoginPage stuff (finally caught what you meant about not using login in pages). Looked at how the other merged PRs handle auth (#59943, #59919, etc.) and matched that pattern - just using the global storageState: AUTH_FILE instead.

Quick summary of what changed:

Removed LoginPage completely
Tests get the authenticated page directly from Playwright config now
All the other stuff you mentioned is addressed too (beforeAll, separate file, filtering)
If there's anything else that needs fixing, let me know and I'll get on it.

But honestly, if you'd rather hand this off to someone else at this point, I totally get it - I know I've already taken up a lot of your time.

Thanks again for the help!

[vatsrahul1001]

@vatsrahul1001

Hey, thanks for sticking with me on this - I know it's taken way longer than it should have. Really appreciate you taking the time to explain the patterns.

Just pushed a fix removing the LoginPage stuff (finally caught what you meant about not using login in pages). Looked at how the other merged PRs handle auth (#59943, #59919, etc.) and matched that pattern - just using the global storageState: AUTH_FILE instead.

Quick summary of what changed:

Removed LoginPage completely Tests get the authenticated page directly from Playwright config now All the other stuff you mentioned is addressed too (beforeAll, separate file, filtering) If there's anything else that needs fixing, let me know and I'll get on it.

But honestly, if you'd rather hand this off to someone else at this point, I totally get it - I know I've already taken up a lot of your time.

Thanks again for the help!

Thanks for the changes @Sahil-Shadwal, I see static checks and tests are still failing can you have a look?

[vatsrahul1001]

@Sahil-Shadwal can you resolve conflicts and look at failing tests?

[Sahil-Shadwal]

@vatsrahul1001 sorry to disappoint , i tried to fix these but i am getting nowhere and i am busy rn so please assign this issue to someone else

[vatsrahul1001]

@vatsrahul1001 sorry to disappoint , i tried to fix these but i am getting nowhere and i am busy rn so please assign this issue to someone else

@Sahil-Shadwal you do not need to be disappoint. Feel free to pick up new issues when you have bandwidth