Add E2E tests for Plugins page #61057

Eason09053360 · 2026-01-26T06:56:27Z

Add E2E tests for Plugins page (/plugins) to verify plugins list display and pagination functionality.

This PR implements:

PluginsPage page object following the Page Object Model pattern
Test specs covering plugins list display and pagination
Tests passing across Chromium, Firefox, and WebKit browsers (24/24 tests passing)

Closes: #60571

Was generative AI tooling used to co-author this PR?

Yes (please specify the tool below)

Generated-by: GitHub Copilot following the guidelines

boring-cyborg · 2026-01-26T06:56:30Z

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

henry3260 · 2026-01-26T10:49:36Z

airflow-core/src/airflow/ui/tests/e2e/specs/plugins.spec.ts

+test.describe("Plugins Pagination", () => {
+  let pluginsPage: PluginsPage;
+
+  test.beforeEach(async ({ page }) => {


I think you have to remove async to fix CI

Applied! Thanks

vatsrahul1001 · 2026-01-26T11:08:11Z

airflow-core/src/airflow/ui/tests/e2e/specs/plugins.spec.ts

+    const pagination = pluginsPage.page.locator('[data-scope="pagination"]');
+    const paginationExists = await pagination.isVisible().catch(() => false);
+
+    if (paginationExists) {


Either ensure enough data exists in the test environment, or fail explicitly if pagination isn't available

await expect(nextButton).toBeVisible(); await expect(nextButton).toBeEnabled();

vatsrahul1001 · 2026-01-26T11:09:58Z

airflow-core/src/airflow/ui/tests/e2e/specs/plugins.spec.ts

+
+    if (paginationExists) {
+      // Check if page 2 button exists and is enabled
+      const page2Button = pagination.getByRole("button", { name: /page 2/i });


If we have already defined page.locator('[data-testid="next"]'); we should use that right?

Consider consolidating to one pagination test using next/prev buttons to align with established patterns.

vatsrahul1001 · 2026-01-26T11:13:39Z

Thanks for this PR @Eason09053360 I have added some review comment.
You have two pagination tests that test similar functionality. Consider keeping one test that uses the next/prev buttons (which aligns with our pattern in dags-list.spec.ts). Please check how its done in existing tests

Eason09053360 · 2026-01-26T13:04:09Z

Thanks for reviewing !You're absolutely right. I've updated the tests to follow the established patterns from dags-list.spec.ts:

Changes :

Consolidated two pagination tests into one comprehensive test
Using predefined paginationNextButton/paginationPrevButton locators instead of creating temporary ones
Removed redundant toBeEnabled() checks

The test now explicitly fails if pagination isn't available, rather than silently passing.

vatsrahul1001 · 2026-01-27T05:48:12Z

Thanks for reviewing !You're absolutely right. I've updated the tests to follow the established patterns from dags-list.spec.ts:

Changes :

Consolidated two pagination tests into one comprehensive test

Using predefined paginationNextButton/paginationPrevButton locators instead of creating temporary ones

Removed redundant toBeEnabled() checks

The test now explicitly fails if pagination isn't available, rather than silently passing.

@Eason09053360 can you look at failing tests

Eason09053360 · 2026-01-27T12:24:27Z

I've implemented (fail explicitly) as shown in the current code. The test will fail with a clear error message when pagination buttons are not visible.

I think there are some problems here.

1.Tests are explicit about the limitation (environment has only 7 built-in plugins)
2.CI will always show 3 failed tests (chromium, firefox, webkit) for pagination

Should I keep the failing pagination test to highlight the environment limitation?
Should I remove the pagination test since:
The environment cannot guarantee sufficient plugins
Is there a way to increase plugins in the test environment that I'm not aware of?

vatsrahul1001 · 2026-01-28T04:37:53Z

I see @vishakha1411 has fixed pagination for plugins in PR

Eason09053360 · 2026-01-28T07:34:24Z

Thank you for pointing me to PR #61059. I've reviewed the fix and understand that Plugins.tsx now correctly implements pagination support

However, the pagination E2E test still fails in the current test environment.
The test environment only has 7 built-in plugins:

I tested with limit=5&offset=0 to trigger pagination:

Expected: 2 pages (5 plugins on page 1, 2 on page 2) → pagination controls should appear
Actual: Pagination controls are not visible in the UI
Root cause: The DataTable component hides pagination controls when conditions in hasPagination are not met:
const hasPagination = initialState?.pagination !== undefined && (pageIndex !== 0 || rows.length !== total);

When navigating to /plugins?limit=5&offset=0, the URL parameters seem to get cleared during React initialization, resulting in all 7 plugins being displayed on a single page without pagination controls.

vatsrahul1001 · 2026-01-29T04:58:10Z

limit=5&offset=0

@Eason09053360 I suggest you to check how we are handling this in eventpage test

Eason09053360 · 2026-02-01T17:42:48Z

I've implemented the pagination test following the EventsPage pattern as suggested. However, I discovered a frontend issue during testing:

Test Results:

6 core tests passing (heading, table, data validation, etc.)
Pagination test skipped due to frontend state initialization issue

Investigation:
When navigating to /plugins?limit=5&offset=0:

URL parameters correctly set
Page displays all 7 plugins (not 5)
Pagination buttons not rendered

Debug Output:

Srabasti

Congratulation for your first PR @Eason09053360!

For the failing static checks, please use " (double quote) instead of single quote. Multiple lines have this issue in addition to here.

Have you reproduced locally by running prek in your branch? Prek will fix any formatting errors, and then you can push the commit from your branch.

vatsrahul1001 · 2026-02-11T15:31:07Z

@Eason09053360 can you take a look at the failures?

- Create PluginsPage page object following POM pattern - Add test specs for plugins list display and pagination - Tests work across Chromium, Firefox, and WebKit browsers - All 24 tests passing Fixes apache#60571

… currently fails in CI due to test environment having only 7 plugins, which is insufficient to trigger pagination UI controls. Seeking guidance on whether to keep failing test or remove it.

- Added debug logging to verify URL params and actual plugin count - Confirmed URL has limit=5 but page displays all 7 plugins - Root cause: Frontend not applying URL limit parameter on initial load - Backend API works correctly (verified in test_plugins.py)

- Reorder methods alphabetically in PluginsPage.ts - Apply code style formatting to plugins.spec.ts - Consolidate pagination test to align with DagsPage pattern - Remove debug logging - Fix async/await linting error

Eason09053360 · 2026-02-12T08:48:11Z

Thanks for reviewing! I rebased the branch to the latest main and the CI passed. It seems the previous failures were unrelated flaky tests.

boring-cyborg bot added the area:UI Related to UI/UX. For Frontend Developers. label Jan 26, 2026

Eason09053360 marked this pull request as ready for review January 26, 2026 07:42

Eason09053360 requested review from choo121600 and vatsrahul1001 as code owners January 26, 2026 07:42

henry3260 reviewed Jan 26, 2026

View reviewed changes

Eason09053360 force-pushed the add-plugins-e2e-tests branch from c9e7eaa to 42589cf Compare January 26, 2026 10:53

vatsrahul1001 reviewed Jan 26, 2026

View reviewed changes

guan404ming mentioned this pull request Jan 27, 2026

added E2E tests for Plugins Page #60571 #61056

Open

Srabasti suggested changes Feb 3, 2026

View reviewed changes

Eason09053360 added 6 commits February 12, 2026 13:59

Add E2E tests for Plugins page

3617ff8

- Create PluginsPage page object following POM pattern - Add test specs for plugins list display and pagination - Tests work across Chromium, Firefox, and WebKit browsers - All 24 tests passing Fixes apache#60571

refactor: consolidate pagination tests to align with dags-list pattern

bc371a3

refactor: consolidate pagination tests and fail explicitly Note: Test…

16d8d4e

… currently fails in CI due to test environment having only 7 plugins, which is insufficient to trigger pagination UI controls. Seeking guidance on whether to keep failing test or remove it.

skip E2E pagination test

bc81947

Apply prek formatting and consolidate pagination test

610bc0b

- Reorder methods alphabetically in PluginsPage.ts - Apply code style formatting to plugins.spec.ts - Consolidate pagination test to align with DagsPage pattern - Remove debug logging - Fix async/await linting error

Eason09053360 force-pushed the add-plugins-e2e-tests branch from ffa2629 to 610bc0b Compare February 12, 2026 06:26

Add E2E tests for Plugins page #61057

Are you sure you want to change the base?

Add E2E tests for Plugins page #61057

Conversation

Eason09053360 commented Jan 26, 2026

Was generative AI tooling used to co-author this PR?

Uh oh!

boring-cyborg bot commented Jan 26, 2026

Uh oh!

henry3260 Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Eason09053360 Jan 26, 2026

Choose a reason for hiding this comment

Uh oh!

vatsrahul1001 Jan 26, 2026

Choose a reason for hiding this comment

Uh oh!

vatsrahul1001 Jan 26, 2026

Choose a reason for hiding this comment

Uh oh!

vatsrahul1001 Jan 26, 2026

Choose a reason for hiding this comment

Uh oh!

vatsrahul1001 Jan 26, 2026

Choose a reason for hiding this comment

Uh oh!

vatsrahul1001 commented Jan 26, 2026

Uh oh!

Eason09053360 commented Jan 26, 2026

Uh oh!

vatsrahul1001 commented Jan 27, 2026

Uh oh!

Eason09053360 commented Jan 27, 2026

Uh oh!

vatsrahul1001 commented Jan 28, 2026

Uh oh!

Eason09053360 commented Jan 28, 2026

Uh oh!

vatsrahul1001 commented Jan 29, 2026

Uh oh!

Eason09053360 commented Feb 1, 2026

Uh oh!

Srabasti left a comment

Choose a reason for hiding this comment

Uh oh!

vatsrahul1001 commented Feb 11, 2026

Uh oh!

Eason09053360 commented Feb 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

henry3260 Jan 26, 2026 •

edited

Loading