Add data-testid attributes to UI elements for E2E testing

[lpgarzonr]

Summary

Add data-testid attributes to UI elements across the webcomponents library to enable reliable E2E testing.

Motivation

E2E tests need stable, semantic selectors to interact with UI elements. Currently, tests must rely on:

• CSS class names (which change with styling updates)
• Tag/element structure (which changes with refactors)
• Text content (which changes with i18n/copy updates)

These selectors are fragile and lead to flaky tests. Adding dedicated data-testid attributes provides a stable contract between components and tests, decoupled from styling and content.

Proposal

Add data-testid attributes to interactive and identifiable UI elements in all webcomponents, following a consistent naming convention.

Priority Components

The following components are the highest priority and should be addressed first:

1. generic-list-view — heavily used in E2E flows; needs test IDs on rows, action buttons, filters, search, pagination, and headers
2. dashboard — entry point for many user journeys; needs test IDs on tiles/cards, sections, and primary actions

Naming Convention (proposed)

• Use kebab-case: data-testid="user-menu-button"
• Prefix with component name where helpful: data-testid="navigation-item-home"
• Keep names semantic and stable (describe purpose, not appearance)

Scope

• Priority 1: generic-list-view — add test IDs to all interactive elements
• Priority 1: dashboard — add test IDs to all interactive elements
• Audit remaining components for elements that need test IDs
• Define and document the naming convention
• Add data-testid to interactive elements (buttons, inputs, links, menu items)
• Add data-testid to key containers/regions used as test anchors
• Document the test IDs as part of the component public API
• Ensure test IDs are preserved through any shadow DOM / slot boundaries where applicable

Benefits

• Reliable E2E tests — selectors are stable across styling and copy changes
• Faster test authoring — clear, discoverable selectors
• Lower maintenance cost — fewer flaky tests, fewer broken selectors after refactors
• Quality signal — consistent test ID coverage indicates testability of the component library

Acceptance Criteria

• Naming convention documented
• generic-list-view and dashboard have full data-testid coverage
• All interactive elements in existing components have data-testid attributes
• New components are required to include data-testid attributes (e.g., via PR template / review checklist)