Избежание этих ловушек поможет вам эффективно применять сквозное тестирование.

Недавно я совместно работал над написанием нового набора сквозных (E2E) тестов для ArcGIS Hub.

Позвольте мне определить, о чем я говорю. E2E-тесты обычно представляют собой автоматизированные тесты графического интерфейса, которые выполняются в реальной системе.

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

Это делает сквозные тесты очень точными, но также создает потенциальные подводные камни. Вот мой совет.

Не пишите их, не определяя причину

Зачем вы пишете эти тесты? В этой статье ² исследователи выделили две основные причины, по которым разработчики пишут эти и другие тесты GUI:

  1. Автоматизированное приемочное тестирование (инкапсуляция ожиданий клиентов).
  2. Автоматизированное регрессионное тестирование (предотвращение ошибок регрессии).

Так какой из них вам? Или это совсем другая причина?

Сформулируйте свою цель и убедитесь, что ваша команда единомышленников по этому поводу. Это гарантирует, что каждый точно понимает цель и ценность этих тестов.

Не повторяйте покрытие

Допустим, вы создали новый компонент пользовательского интерфейса. Если вы можете охватить функциональность в модульном тесте (или как там это называется в вашей конкретной структуре), сделайте это там!

Модульные тесты, как правило, легче поддерживать, они менее сложны и менее затратны для запуска в конвейере CI.

E2E-тесты должны охватывать только те области, которые они могут охватить. Обычно это общие пользовательские истории, охватывающие множество компонентов и представлений. Мы говорим о крупных потоках высокой стоимости, например:

  • Подписываясь.
  • Вход и выход.
  • Создание нового ‹того, что пользователи создают в вашем приложении›, и предоставление доступа к нему.
  • Обновление информации профиля пользователя.

Не используйте одноуровневую архитектуру

В веб-контексте однослойная тестовая архитектура E2E будет выглядеть следующим образом (поэтому этого следует избегать):

Если вы используете однослойную архитектуру для своего набора тестов E2E, вы попадете в мир боли.

В частности, вы (и другие) найдете:

  • Тесты трудны для понимания и, следовательно, для отладки. Смешивание высокоуровневой и низкоуровневой логики приведет к слишком большому количеству деталей в тестах.
  • Относительно незначительные изменения пользовательского интерфейса нарушат многие тесты. Это связано с тем, что логика и селекторы HTML будут массово дублироваться, создавая множество точек отказа .
  • При изменении пользовательского интерфейса потребуется обновить большую часть вашего набора тестов. Это соответствует предыдущему пункту.
  • Вы не сможете повторно использовать части логики тестирования. Это создаст дополнительные усилия и вызовет головную боль.
  • Мой голос может прозвучать в твоей голове… смеяться над твоей болью.

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

В частности, я рекомендую использовать объектную модель страницы. См. Статью ³ Мартина Фаулера, чтобы узнать больше.

Не используйте ломающиеся селекторы

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

В веб-контексте есть несколько способов найти конкретный элемент, и не все они одинаково устойчивы к изменениям в пользовательском интерфейсе.

Позвольте мне оценить их в порядке взлома.

  1. Селектор CSS (например, .sign-in-btn). Классы могут измениться, поэтому они могут быть нарушены.
  2. Селектор :nth-child(). Похоже, что порядок элементов на одном иерархическом уровне может быть переупорядочен. Кроме того, эти селекторы часто не являются описательными, что затрудняет понимание сообщений об ошибках от вашего средства выполнения тестов.
  3. Селектор области видимости (например, .img-view .container .img-wrapper img). Кажется, что этот вариант изменится с меньшей вероятностью, чем два предыдущих, потому что иерархия элементов более неизменна. Однако его также обычно смешивают с селекторами CSS.
  4. Селектор идентификатора (например, #thumbnail). Кажется, что идентификаторы почти никогда не меняются, но могут. Также могут быть другие причины избегать добавления их к элементам, например, если структура пользовательского интерфейса, которую вы используете, использует вставки и полагается на них внутри.
  5. Атрибут data-test=”some-unique-slug”. Это атрибут, добавляемый к целевому элементу исключительно для того, чтобы дать тесту дескриптор. Он может быть сколь угодно информативным, и, если значение уникально, тест сможет его найти. Он полностью невосприимчив к изменениям макета, идентификатора, стилей и даже типа элемента. Кроме того, большинство разработчиков / UX-специалистов знают, что с этим не стоит связываться. Это серебряная пуля.

Я не собираюсь проповедовать адский огонь против CSS-селекторов. Вы сами решаете, каким селекторам доверять.

Однако, если бы это было на мое усмотрение, я бы каждый раз выбирал data-test атрибутов. Когда мои тесты E2E терпят неудачу, я не хочу, чтобы это было из-за смены стиля.

Не ждите, что ваш люкс будет необслуживаемым

Когда вы создаете набор тестов E2E, он становится отражением пользовательского интерфейса вашего приложения.

Как часто этот интерфейс будет меняться в следующем году? Верно. Все время. Итак, отражение должно развиваться вместе с ним. Вы и ваша команда должны принять и принять факт непрерывного тестирования.

В противном случае вы, скорее всего, столкнетесь с враждебными отношениями со своим набором тестов. Из-за этого они станут нестабильными, надоедливыми и будут игнорироваться. Если вы позволите этому случиться, вы потратите зря свои усилия!

Не игнорируйте нестабильные тесты

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

Я заметил, что это еще более заметно в контексте сквозного тестирования. И поскольку тесты E2E полагаются на действующие внешние системы, требуются дополнительные усилия, чтобы убедиться, что они не дают случайного сбоя из-за недетерминированных факторов, таких как состояние сети, текущая нагрузка на внешние службы и т. Д.

Усилия того стоят. Если тесты будут слишком нестабильными, разработчики им не поверят. Они просто не будут. Тесты станут не полезными, а раздражающими.

Каждый слоеный тест индивидуален. Тесту может потребоваться больше времени для загрузки представления или может потребоваться что-то еще. Тем не менее, мой совет - либо укрепить его, либо удалить. Не оставляйте его там, чтобы запятнать репутацию люкса.

Автоматическое сообщение базовой телеметрии, такой как продолжительность выполнения и сбой / успех, на интерфейс панели мониторинга может помочь в выявлении проблемных тестов. Мы используем Elastic's Kibana.

Заключение

Сквозные тесты могут быть мощным инструментом как для выражения ожиданий пользователей, так и для защиты от регрессов. Я считаю, что они абсолютно заслуживают место в арсенале разработчика.

Избежание этих ловушек поможет вам применить этот полезный инструмент с максимальной эффективностью.

использованная литература

[1] Некоторые фреймворки, такие как Cypress действительно предоставляют XHR-запросы и имитацию DOM. Это может быть очень полезно, но имейте в виду, что, хотя эти функции могут уменьшить нестабильность, всякий раз, когда вы имитируете внешнюю систему, вы снижаете точность вашего теста.

[2] Хеллманн, Т. Д., Моазцен, Э., Шарма, А., Акбар, З., Силлито, Дж., И Маурер, Ф. (2014). Исследовательское исследование автоматизированного тестирования графического интерфейса пользователя: цели, проблемы и передовой опыт. ("Внешняя ссылка")

[3] Фаулер М. (2013). PageObject. Получено с https://martinfowler.com/bliki/PageObject.html.