add cypress coverage for manage columns behaviour in hardware conf table

[Philip-Carneiro]

Description

Added cypress coverage to Manage Columns in Hardware Configuration Table

How Has This Been Tested?

Merge criteria:

• All the commits have been signed-off (To pass the DCO check)

• The commits have meaningful messages
• Automated tests are provided as part of the PR for major new functionalities; testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
• The developer has manually tested the changes and verified that the changes work.
• Code changes follow the kubeflow contribution guidelines.
• For first time contributors: Please reach out to the Reviewers to ensure all tests are being run, ensuring the label ok-to-test has been added to the PR.

If you have UI changes

• The developer has added tests or explained why testing cannot be added.
• Included any necessary screenshots or gifs if it was a UI change.
• Verify that UI/UX changes conform the UX guidelines for Kubeflow.

[manaswinidas]

Thanks for adding Cypress coverage for manage columns! A few items to clean up around DRY and redundant assertions.

[manaswinidas]

Informational — library coverage gap

9 of the 16 tests here (toggle, cancel, persist, restore-defaults, search) exercise ManageColumnsModal / useManageColumns behavior from mod-arch-shared. The mod-arch-library repo has test infrastructure (both Cypress and unit) but zero coverage for these components today.

These tests are valuable as the only coverage that currently exists, so not blocking on this — but ideally this coverage should move upstream as unit/component tests in mod-arch-library, leaving only a smoke test + the app-specific latency filter interaction tests here.

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from manaswinidas. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• clients/ui/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[manaswinidas]

Reiterating my previous comment, 10 of 16 tests exercise generic ManageColumnsModal / useManageColumns behavior and could move upstream to mod-arch-library as unit/component tests. This would leave only a smoke test (open modal, toggle one column) plus the 5 app-specific latency filter interaction tests here. Can we move them ?

[Philip-Carneiro]

Informational — library coverage gap

9 of the 16 tests here (toggle, cancel, persist, restore-defaults, search) exercise ManageColumnsModal / useManageColumns behavior from mod-arch-shared. The mod-arch-library repo has test infrastructure (both Cypress and unit) but zero coverage for these components today.

These tests are valuable as the only coverage that currently exists, so not blocking on this — but ideally this coverage should move upstream as unit/component tests in mod-arch-library, leaving only a smoke test + the app-specific latency filter interaction tests here.

I moved the tests to the place you suggested o/

[Philip-Carneiro]

/retest

[google-oss-prow]

@Philip-Carneiro: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

Details

In response to this:

/retest

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[ppadti]

/retest

[manaswinidas]

This needs to wait for the other PR to go in and we should remove any tautological/repetitive tests

[Philip-Carneiro]

This needs to wait for the other PR to go in and we should remove any tautological/repetitive tests

The other PR has been merged and this branch has been rebased on top of it.

Regarding tautological/repetitive tests — I did a thorough comparison between the Cypress tests in this PR and the unit tests from the mod-arch PR. They operate at different levels of the testing pyramid and cover different scopes:

• Cypress tests (this PR): Test the integrated behavior in the Model Catalog contex, sticky columns exclusion, latency filter interaction with column visibility, and end-to-end modal workflows on the Hardware Configuration table.
• Unit tests (mod-arch PR): Test the generic ManageColumnsModal component and useManageColumns hook in isolation, toggle callbacks, cancel behavior, search filtering, localStorage persistence, restore defaults.

The only partial overlap is the "modal opens with controls" smoke test, which exists in both — but the Cypress version navigates through the real application while the unit test renders the component with mocked props. No tests were found to be duplicated or redundant.