Избежание этих ловушек поможет вам эффективно применять сквозное тестирование.
Недавно я совместно работал над написанием нового набора сквозных (E2E) тестов для ArcGIS Hub.
Позвольте мне определить, о чем я говорю. E2E-тесты обычно представляют собой автоматизированные тесты графического интерфейса, которые выполняются в реальной системе.
В веб-контексте средство запуска сквозных тестов часто удаленно автоматизирует браузер. Это означает, что классические инструменты модульного тестирования - имитация, заглушка, доступ к внутреннему состоянию и т. Д. - обычно недоступны.
Это делает сквозные тесты очень точными, но также создает потенциальные подводные камни. Вот мой совет.
Не пишите их, не определяя причину
Зачем вы пишете эти тесты? В этой статье ² исследователи выделили две основные причины, по которым разработчики пишут эти и другие тесты GUI:
- Автоматизированное приемочное тестирование (инкапсуляция ожиданий клиентов).
- Автоматизированное регрессионное тестирование (предотвращение ошибок регрессии).
Так какой из них вам? Или это совсем другая причина?
Сформулируйте свою цель и убедитесь, что ваша команда единомышленников по этому поводу. Это гарантирует, что каждый точно понимает цель и ценность этих тестов.
Не повторяйте покрытие
Допустим, вы создали новый компонент пользовательского интерфейса. Если вы можете охватить функциональность в модульном тесте (или как там это называется в вашей конкретной структуре), сделайте это там!
Модульные тесты, как правило, легче поддерживать, они менее сложны и менее затратны для запуска в конвейере CI.
E2E-тесты должны охватывать только те области, которые они могут охватить. Обычно это общие пользовательские истории, охватывающие множество компонентов и представлений. Мы говорим о крупных потоках высокой стоимости, например:
- Подписываясь.
- Вход и выход.
- Создание нового ‹того, что пользователи создают в вашем приложении›, и предоставление доступа к нему.
- Обновление информации профиля пользователя.
Не используйте одноуровневую архитектуру
В веб-контексте однослойная тестовая архитектура E2E будет выглядеть следующим образом (поэтому этого следует избегать):
Если вы используете однослойную архитектуру для своего набора тестов E2E, вы попадете в мир боли.
В частности, вы (и другие) найдете:
- Тесты трудны для понимания и, следовательно, для отладки. Смешивание высокоуровневой и низкоуровневой логики приведет к слишком большому количеству деталей в тестах.
- Относительно незначительные изменения пользовательского интерфейса нарушат многие тесты. Это связано с тем, что логика и селекторы HTML будут массово дублироваться, создавая множество точек отказа .
- При изменении пользовательского интерфейса потребуется обновить большую часть вашего набора тестов. Это соответствует предыдущему пункту.
- Вы не сможете повторно использовать части логики тестирования. Это создаст дополнительные усилия и вызовет головную боль.
- Мой голос может прозвучать в твоей голове… смеяться над твоей болью.
Вместо этого используйте многоуровневую архитектуру, которая позволяет самим тестам быть понятным выражением пользовательских историй. Скрыть логику и селекторы, зависящие от области, в промежуточных слоях.
В частности, я рекомендую использовать объектную модель страницы. См. Статью ³ Мартина Фаулера, чтобы узнать больше.
Не используйте ломающиеся селекторы
Этот раздел специально ориентирован на мою специальность, веб-разработку, но всегда применим принцип использования надежных методов для получения правильного элемента пользовательского интерфейса.
В веб-контексте есть несколько способов найти конкретный элемент, и не все они одинаково устойчивы к изменениям в пользовательском интерфейсе.
Позвольте мне оценить их в порядке взлома.
- Селектор CSS (например,
.sign-in-btn
). Классы могут измениться, поэтому они могут быть нарушены. - Селектор
:nth-child()
. Похоже, что порядок элементов на одном иерархическом уровне может быть переупорядочен. Кроме того, эти селекторы часто не являются описательными, что затрудняет понимание сообщений об ошибках от вашего средства выполнения тестов. - Селектор области видимости (например,
.img-view .container .img-wrapper img
). Кажется, что этот вариант изменится с меньшей вероятностью, чем два предыдущих, потому что иерархия элементов более неизменна. Однако его также обычно смешивают с селекторами CSS. - Селектор идентификатора (например,
#thumbnail
). Кажется, что идентификаторы почти никогда не меняются, но могут. Также могут быть другие причины избегать добавления их к элементам, например, если структура пользовательского интерфейса, которую вы используете, использует вставки и полагается на них внутри. - Атрибут
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.