Data Test IDs

data-test-ids.md

A data-testid attribute should be included for every testable element. Testable elements are defined as elements which the user interacts with or which has dynamically changing content.

Usage

• <MyComp data-testid={...}>

Format

{namespace}.{nav item}.{page component}.[distinguisher]

• Namespace

  • active product from the ProductMenu

  • mg for Mailgun, ir for InboxReady, portal for settings/shared components

• Navigation item

  • What the user clicked to arrive at the tested content

  • In most cases, refers to the left side menu, potentially with child option: - dashboard - sendingDomains - inboxPlacementSeedLists

  • May also refer to ProfileMenu options: - profileMenuAccountSettingsPlan&Billing - profileMenuEmailSettingsDomainMonitoring

• Page component

  • Prefixed with the feature name plus a container type suffix

  • Type of containers content exists within:

    • Card - non-interactive display element
    • Panel - Like a card, but with a header and interactive UX elements
    • Tab - if the content requires clicking on a tab to reveal
    • Table/TableRow - content displayed within a table or the specific row of a table
    • Details - Typically, when a table row shows expanded content

  • 

• Distinguisher

  • Optional when only the page component needs to be selected

  • Uniquely identifies the selectable content within the feature group

  • When interactable, identifies control type: select, button, input, etc.

  • Graph When refering to infographics: lineGraph, barGraph, or pieGraph

• Examples

  • mg.dashboard.deliveredStatCard.percentage
  • mg.dashboard.deliveredStatCard.count
  • mg.dashboard.deliveredStatCard.total
  • mg.sendingIps.ipAddressesTable.search
  • mg.sendingIps.ipAddressesTableRow.address
  • mg.receiving.testYourRoutePanel.testButton
  • ir.verificationsVerify.verifyAddressesInBulkTab.remaining
  • ir.verificationsVerify.verifyAddressesInBulkTab.slider
  • ir.verificationsVerify.verifyAddressesInBulkTab.estimationInput
  • ir.verificationsVerify.verifiedListsTable.actionsButton
  • ir.verificationsVerify.verifiedListsDetails.summaryPieGraph
  • ir.verificationsVerify.verifiedListsDetails.riskHigh

A data-testid attribute should be included for any element which the user interacts with or which has dynamically changing content

Nitpicky, but I would phrase this as "...should be included for any testable elements. Testable elements are defined as elements which the user interacts with or which has dynamically changing content"

Format
<namespace>.<nav item>.<page component>.[distinguisher]

Theres one main why I think that pattern, as described, might be a little problematic.

• E2E tests are self-contained within the libraries they are meant to test
  • Because of this, tests for StatsCards (like in the examples above), would belong in the library where the StatsCard component lives in, i.e. shared-ui. With this in mind, it's clear that we that the <namespace>.<page component> part of the pattern won't always work. (Which, I think you did already imply with <page component>)

Consider the following examples with this pattern.

<libraryName.featurePart.componentName.componentIdentifier>

libraryName = NX library
featurePart = (Optional): Feature parts within a feature lib
componentName = Name of component
componentIdentifier = (Optional): Used to identify multiple parts of a component

• Examples:
  • shared-ui.statCard.percentage
  • shared-ui.statCard.count
  • shared-ui.statCard.total
  • dashboard-ui.sendingStatsPanel.dashboardRangeSelector.inputDate
  • dashboard-ui.sendingStatsPanel.dashboardRangeSelector.calendar
  • dashboard-ui.sendingStatsPanel.dashboardRangeSelector.applyButton
  • dashboard-ui.greetingHeader

This pattern keeps it simple and makes it really easy to know where that component lives when looking at the DOM during testing.

When testing shared-ui libs, for example, it should be up to the shared lib and the component being tested to determine what app(s) that component is tested against. For feature UI libs, that decision will usually already be made for us.

Also FWIW, the rest of the examples is all content still within the CockpitMfe. We do not currently have an established testing pattern/structure for testing code within Cockpit.

<libraryName.featurePart.componentName.componentIdentifier>

Thinking even further, we might not even need featurePart since we really shouldn't have multiple components named the same within the same lib.