Add test attributes to selectable components

[ohmnoms]

Adding configurable data- attributes (e.g. data-aui or similar) to key selectable elements would greatly enhance testability and maintainability of automation scripts while avoiding any potential changes to class names or attributes.

---

Proposal

• Target Areas:

  • Tree node containers
  • Expand/Collapse toggles
  • Selection checkboxes or clickable text

• Implementation Idea:

  • Introduce inputs like testIdPrefix?: string and testIdAttr?: string on the component so users can specify a prefix or naming convention for test attributes.

Example Usage

<ngx-json-treeview
  [items]="items"
  [config]="config"
  [testIdPrefix]="'jsonTree'"
  [testIdAttr]="'data-aui'"
></ngx-json-treeview>

---

<div class="segment" data-aui="jsonTree-node-123">
  <div class="toggler" data-aui="jsonTree-toggle-123">⯈</button>
</div>

[ohmnoms]

@MichaelDoyle Thanks for making this. I'm using Playwright in an app using the viewer and would like to leverage the test IDs. Let me know if you think this is a good idea or have any suggestions to the proposal. I can take a stab at it if you'd like

[MichaelDoyle]

@ohmnoms great suggestion!

I am not strictly opposed to doing testids (I use them in my work often), but I do wonder if this is a good opportunity to make the component more accessible via ARIA roles and semantic tags (which in turn will make testing easier at the same time). In other words:

1. Make use of ARIA roles as appropriate
2. Use html elements that are more semantically appropriate such as button (right now pretty much everything is s div and/or span)

In particular tree / treeitem seems like it fits well: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/treeitem_role

Do you use the Playwright's role locators anywhere in your tests? Or are you strictly using testid? Curious to hear more about your needs here.

https://playwright.dev/docs/locators#locate-by-role

How would you suggest generating the testids (i.e. after the prefix)? With a potentially large number of nodes being rendered, I wonder how usable the testids will be at scale, versus just matching on the content in the node itself in combination with the role. e.g.)

const node = page.getByRole('treeitem', { name: /"some value":/ });`

[MichaelDoyle]

I was thinking something along these lines, WDYT?

#30

If that still doesn't meet your testing goals we can also look at adding some testid capabilities.

[ohmnoms]

@MichaelDoyle Yes, that will definitely work and serves the 2 purposes. Looking at the playwright docs you can combine the aria role with options to get what you need. So something like:

await page
  .getByRole('treeitem', { level: 3 })
  .filter({ hasText: /"{segment-text}"/i })
  .locator('button.expandable')
  .click();

would get the node needed without a test attribute, which is much less verbose than what I'm doing now to target specific elements.

We're typically adding testids where we can, and role locators where they aren't as easily added (for instance in certain Angular Material components that show up in the cdk-overlay or aren't directly written in the DOM.

[MichaelDoyle]

Published 20.0.1. 🍻 Thanks!

[ohmnoms]

Thank you!