Передовой опыт E2E-тестирования по использованию атрибутов данных

Обратите внимание, что это основано на моем опыте управления огромными наборами тестов на предприятии и нескольких раз, когда я шел по неверному пути именно по этой проблеме. Здесь есть много компромиссов и нет единственного «правильного пути».

Атрибуты данных

Во-первых, правильно отделить селекторы от внутренних атрибутов DOM, которые являются деталями реализации, такими как атрибут класса и т. д.

Атрибуты данных могут стать частью решения этой проблемы. Однако вы должны знать о недостатках, прежде чем совершать их в одностороннем порядке. Они хороши тем, что вы можете отделить тестовый код от деталей реализации уровня приложения (class) и т. д.

Раньше я видел и использовал такие соглашения, как использование data-cy-component, который представляет тип «компонента», который представляет этот элемент DOM, в сочетании с атрибутами «специфического компонента», связанными с этим компонентом. Например:

<tbody>
  <tr data-cy-component = "row" data-cy-row-id = "1">
    <td data-cy-component = "cell" data-cy-cell-column = "name">...
    <td data-cy-component = "cell" data-cy-cell-column = "email">...
    <td data-cy-component = "cell" data-cy-cell-column = "phone">...

Это:

• С пуристской точки зрения чище, чем составные значения.
• Более расширяемый, вы можете добавить больше тестовых атрибутов, если вам нужно выбрать что-то по-новому, не нарушая при этом все селекторы.
• Устраняет двусмысленность (что, если в названии столбца есть -?).

Однако, с отрицательной стороны:

• По сути, вы возлагаете повышенную нагрузку на разработчиков приложений, получающих правильные комбинации. Что, если они забудут добавить один из атрибутов? Это более сложно, и существует больше способов ошибиться, поскольку эвристику того, что относится к тому, что вы определяете, зависит от вас, и каждый должен ее придерживаться. Это не так просто, как кажется.
• Он предлагает людям не только выбирать эти атрибуты, но также читать их и утверждать на их основе. Например. используйте значение. Это вообще плохо. Пользователь не читает это значение. В конце концов, вы пытаетесь доказать то, что действительно может видеть пользователь.
• Вы по-прежнему принципиально добавляете новый «уровень» деталей реализации, хотя и поддерживаемый отдельно и более стабильный. Пользователь не знает атрибутов данных и не заботится об них. Происходит перекос. Например, вы можете успешно захватить нужный столбец, но отображается ли на экране заголовок столбца с правильным именем?

Доступные селекторы

cypress-testing-library — это пример библиотеки, которая поощряет использование селекторов, основанных на данных DOM, которые существуют по соображениям доступности (которые считаются «общедоступными» или видимыми. Его рекомендации, которым отдать предпочтение весьма красноречивы в отношении концептуального мышления.

Это означает использование видимого текста или ролей aria и их атрибутов для решения проблемы. Это дает огромные преимущества:

• Обычно вы тестируете то, что считается общедоступным интерфейсом, и часто используете реальный видимый текст. Вместо случайного тестирования атрибутов данных, которые могут отражать, а могут и не отражать реальность. Это позволяет избежать ложного чувства безопасности.
• Если вам сложно выбрать что-то доступными методами, это обычно означает, что ваша страница недоступна. Итак, вы делаете это так, и это хорошо для всех.
• Вы не запутаетесь в управлении соглашениями об атрибутах данных, поскольку атрибуты aria четко определены и являются частью общедоступных стандартов.
• Если селекторы часто ломаются, это означает, что у вас есть проблема с доступом, которую нужно исправить, и это полезно знать!
• Если вы не можете устранить неоднозначность с помощью доступных селекторов, скажем, если у двух пользователей одинаковое имя, то как пользователь их вообще различает? Это может привести к правильному мышлению о том, как думает пользователь. Вероятно, электронная почта уникальна, поэтому выбирать следует из нее. Это также, что очень важно, заметно.
• Многие библиотеки и системы дизайна уже реализуют атрибуты aria. Например Чакра. А такие вещи, как Zag, могут помочь вам создавать свои собственные вещи доступным способом.

Обратите внимание, что он не запрещает использование тестовых атрибутов, но также ограничивает вас использованием отдельного атрибута data-testid, исключая описанное выше решение составного атрибута (по крайней мере, без добавления собственных аварийных люков). Но обычно вы обнаруживаете, что вам это все равно не нужно в сочетании с существующими доступными селекторами.

В вашем примере вы сначала должны использовать правильную разметку aria, например:

<table aria-label = "Users table">
<thead>
   <tr>
     <th id = "name-column">Name</th>
     <th id = "email-column">Email</th>
     <th id = "phone-column">Phone</th>
   </tr>
</thead>
<tbody>
  <tr>
    <td aria-describedby = "name-column">...
    <td aria-describedby = "email-column">...
    <td aria-describedby = "phone-column">...
  </tr>
  <tr> ...

Затем для выполнения различных задач:

cy.findByRole('table', {name: "Users table"}).within(() => {

   // Getting a row by its unique id that is visible (email)
   cy.findByRole('cell', {description: 'Email', name: '[email protected]'})
      .should('exist)
      .parent()
      .within(() => {
         cy.findByRole('cell', {description: 'Name'}) // Getting the name cell for that same row
           .should('have.text', 'Shaggy Rogers') 
       })
})

Также стоит отметить, что таблицы представляют собой особенно более сложный случай. С cypress-testing-library найти и нажать кнопку проще простого. При работе с таблицами (но в любом случае это справедливо для подхода с атрибутами данных) вам, вероятно, захочется зарегистрировать некоторые общие команды.

Теперь, чтобы решить вашу проблему:

но все равно остались бы тонны разметки, которая не была бы покрыта, если бы, возможно, я не начал использовать role= во всем, что кажется грязным хаком и, вероятно, противоречит ARIA или какому-то другому стандарту w3c.

Не ставьте role на что-либо, если это не то, о чем вы говорите. Если да, то вам следует это сделать. Обратите внимание, что вам также не нужно устанавливать role для вещей, которые уже имеют правильный role, поскольку элементы HTML уже имеют разные роли по умолчанию.

С атрибутами арии вы можете зайти невероятно далеко. Если вы чувствуете, что вам нужно больше, это часто происходит потому, что вы пытаетесь сделать что-то, что является плохой практикой, т. е. выбираете что-то невидимое. Но если вам абсолютно необходимо, вы все равно можете использовать базовые атрибуты данных с cypress-testing-library в тех редких случаях, когда вам нужно уйти.

Однако прежде чем это сделать, я обычно добавляю осмысленный aria-label или aria-describedby и использую его. В конце концов, aria-label чего-то должно правильно резюмировать, что это за вещь.

Это новая разметка, но она соответствует стандартам, она выдержит испытание временем и в любом случае необходима для доступа.

И помните, селекторы — это только один уровень надежной абстракции. Это нормально и даже ожидается создание оболочек с общими командами, которые достигают определенных обходов или утверждений.

По моему опыту, это правильный путь. Вы повышаете уверенность в тестах и ​​заставляете думать о правильных вещах.