Как вы можете написать тесты для Selenium (или аналогичные), которые не терпят неудачу из-за незначительных или косметических изменений?

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

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

Итак, вы написали тесты на селен (или другие подобные), и как вы справляетесь с хрупкой природой тестов (или как вы не позволяете им быть хрупкими), и для каких тестов вы используете селен?

testing selenium

— Сэм Дж
источник

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

— talonx

@talonx - недостаточно просто запустить такой тест, если небольшое изменение приведет к значительному изменению пакета, это будет проблематично, независимо от того, запускаются ли они разработчиком, блоком ci или тестерами

— FinnNk

@FinnNK: Согласитесь - небольшие изменения не должны приводить к большим изменениям. Это означает, что тестовые случаи были написаны кем-то, кто не связывался с разработчиками, делающими изменения - пахнет как пробел в коммуникации.

— talonx

@talonx: UI-тесты по своей природе хрупкие и занимают гораздо больше времени, чем юнит-тесты. Это особая задача, поэтому я бы не стал спешить с выводами разработчиков в организации @ Sam.

— ажеглов

Я изменил название - надеюсь, немного более представительный вопрос и чуть менее отрицательный.

— Джон Хопкинс

Ответы:

Целью Selenium является создание интеграционных тестов на основе пользовательского интерфейса .

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

Тесты, управляемые пользовательским интерфейсом, по своей природе хрупки, хотя Selenium и Watir - шаг вперед по сравнению с ранними днями инструментов записи и воспроизведения . Есть несколько способов решения этой проблемы - вот несколько советов от экспертов мирового уровня:

Не пытайтесь получить все ваши тестовые покрытия из этого типа тестов . Роберт К. Мартин утверждает, что ваш охват кода интеграционными тестами должен составлять около 20% . Просто нецелесообразно проверять все пути выполнения, когда входные данные находятся на расстоянии нескольких уровней приложения.

Получите большую часть тестового покрытия от юнит-и приемочных испытаний . Ищите ссылки на статьи Гойко Адзича в ответе FinnNk . Adzic неоднократно спорил о тестировании бизнес-логики с помощью приемочных тестов и обхода пользовательского интерфейса.

Но некоторое количество UI-ориентированных тестов еще нужно написать . Здесь вам понадобятся некоторые практические советы, а не «не проверяйте свою бизнес-логику через пользовательский интерфейс». Я бы порекомендовал блог Патрика Уилсона-Уэлша в качестве отправной точки.

— azheglov
источник

Ссылка на patrickwilsonwelsh.com больше не работает, и другой ресурс для этого .. !!

— MarmiK

Самая важная вещь при создании таких тестов после прохождения тривиального числа - это идея симметричного изменения - небольшое изменение в коде должно привести к небольшому изменению в наборе тестов.

Например, допустим, вы собрали чье-то имя с двумя текстовыми полями в 100 тестах. Если вы пишете эти тесты niavely (или, возможно, используете запись-воспроизведение), то у вас будет 100 тестов для изменения. Если вместо этого вы абстрагируете шаг «введите имя» и используете его в своих тестах вместо непосредственного использования селена, то у вас есть только 1 место для внесения изменений. От вашего контекста будет зависеть, сколько слоев абстракции вы используете, но использование абстракции будет иметь большое значение для обеспечения удобства сопровождения ваших тестов.

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

Гойко Адзич имеет много полезных советов в своем блоге, когда речь заходит о такого рода тестах - посмотрите его Синус Смерти и, в частности, как его избежать .

— FinnNk
источник

Полезные советы FinnNk - я абстрагировал общие методы (вход в систему, поиск виджетов на боковой панели и т. д.), поэтому при изменении тестов ущерб уменьшается К сожалению, мы используем специальную систему, которая создает некоторые виджеты и создает идентификаторы для виджетов на основе их положения в DOM, поэтому, когда что-то перемещается, тесты не выполняются.

— Сэм Дж

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

— FinnNk

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

Лично я считаю, что если наличие <div>тега нарушает тест, то этот тест неоправданно строго зависит от окружающих тегов, и следует применять более мягкий подход.