Adding HTML Attributes (data-ms-id) to Elements to Make UI Testing Easier

[MarkBremer]

MIP - Adding HTML Attributes (cy-data) to Elements to Make UI Testing Easier

Overview

This proposal adds Cypress selectors across the UI by adding consistent 'data-ms-id' attributes to key elements

We are currently working on automated UI testing with Cypress for GeoNode, and right now even small UI changes can break tests.
By adding consistent attributes, we decouple tests from visual/layout changes and make the suite more robust and maintainable.

Here are some proposals: cy-tags.pdf
These are already implemented in a forked project.
Of course, we can discuss the naming conventions.

Here is an example:

"data-ms-id": "btn-add-resource"
"data-ms-id": "btn-add-resource-upload-dataset"
"data-ms-id": "btn-add-resource-upload-document"
"data-ms-id": "btn-add-resource-create-dataset"

Affected projects:

• MapStore2
• Geonode MapStore Client

Proposed By

@ffischer1984
@jo-schie
@mapme-initiative

Assigned to Release

State

• Under Discussion
• In Progress
• Completed
• Rejected
• Deferred

Motivation

The current UI is missing consistent HTML attributes for automated testing, which makes Cypress tests fragile and harder to maintain.

Key benefits:
Higher test stability: selectors are explicit and less sensitive to layout or style changes.
Better maintainability: a consistent naming convention reduces ambiguity and duplicate selector logic.
Safer UI evolution: teams can refactor visuals/classes without breaking end-to-end tests.

Proposal

Backwards Compatibility

This change is fully backward compatible.

It only adds HTML attributes and does not alter API contracts, routing, permissions, or user-facing behavior. Existing functionality remains unchanged, while automated tests gain stable selectors.

Future evolution

Feedback

Voting

Project Steering Committee:

• @tdipisa: +1
• @offtherailz: +1
• @allyoucanmap: +1
• @MV88: +1
• @giohappy: +1

Links

• Email Discussion
• Pull Request
• Linked Issue

[giohappy]

Thanks for this MIP @MarkBremer .
It will be reviewed asap by the PSC.

[tdipisa]

Thank you for submitting this MIP. We would like to inform you that the issue has been successfully received and assigned to our technical team for review.

We are currently processing the proposal and will provide an update as soon as possible. No further action is required on your part at this time.

Best regards,
The MapStore Team

[m13v]

consistent test selectors are the single biggest stability win for any E2E suite. one thing to consider though, cy-data is Cypress-specific naming convention. if you ever migrate to Playwright (or run both), data-testid is more universal and supported natively by Playwright's getByTestId(). we went through a similar tagging exercise and settled on a naming pattern like data-testid="resource-action-element" which makes tests readable without having to check the component tree. also worth adding the attributes to loading states and error messages, not just interactive elements. flaky waits usually come from not having a testable indicator for when async operations complete.

[m13v]

we built a test automation framework that handles the selector strategy across different UI frameworks. the element targeting with fallback chains (tries data-testid first, falls back through role and text selectors scoped to parent) is here: https://github.com/mediar-ai/terminator/blob/main/crates/terminator/src/element.rs

[allyoucanmap]

@MarkBremer thanks for the proposal, I think this would be a good enhancement for MapStore.

I agree that the attribute naming should be more generic and not associated to cypress (as @m13v is suggesting) something as data-test-id could work for me but I'm open to alternative proposal using the data-* attribute.

[MV88]

I agree with @allyoucanmap +1 for me

[giohappy]

I agree with the comments. A standard data-* follows the standards, outside the selected suite.

@MarkBremer, the MS team is assessing the best approach for the tagging, but the cy-* won't be adopted.
I don't know if you're willing to keep this MIP open and adapt it to the approach that will surface from the discussion. Otherwise, I think this can be closed and reopened with the selected approach.

[tdipisa]

Dear @MarkBremer thank you so much. I totally agree with the need you highlighted with the topic of this MIP.
Anyway, I also agree with concerns reported by @giohappy and @allyoucanmap which are important to have the system test-suite agnostic.
Therefore, we are waiting for your feedback to see if you maybe want to redefine the approach here or you prefer to open a new MIP. Thank you so much in advance.

[allyoucanmap]

discussing with @giohappy the attribute name could be also generic as data-ms-id