Я провел последнюю неделю или около того, изучая селен и создавая серию веб-тестов для веб-сайта, который мы собираемся запустить. это было здорово учиться, и я выбрал некоторые методы локации xpath и css.
Однако для меня проблема в том, что небольшие изменения нарушают тесты - любое изменение в div, id или каком-либо числе с автоматическим идентификатором, которое помогает идентифицировать виджеты, нарушает любое количество тестов - это просто кажется очень хрупким.
Итак, вы написали тесты на селен (или другие подобные), и как вы справляетесь с хрупкой природой тестов (или как вы не позволяете им быть хрупкими), и для каких тестов вы используете селен?
Ответы:
Целью Selenium является создание интеграционных тестов на основе пользовательского интерфейса .
Интеграционные тесты проверяют правильность работы всех компонентов вашей системы при совместном развертывании. Интеграционные тесты не являются достаточной стратегией тестирования и дополняют другие стратегии тестирования, имеющие другую направленность, например модульное тестирование и приемочное тестирование .
Тесты, управляемые пользовательским интерфейсом, по своей природе хрупки, хотя Selenium и Watir - шаг вперед по сравнению с ранними днями инструментов записи и воспроизведения . Есть несколько способов решения этой проблемы - вот несколько советов от экспертов мирового уровня:
Не пытайтесь получить все ваши тестовые покрытия из этого типа тестов . Роберт К. Мартин утверждает, что ваш охват кода интеграционными тестами должен составлять около 20% . Просто нецелесообразно проверять все пути выполнения, когда входные данные находятся на расстоянии нескольких уровней приложения.
Получите большую часть тестового покрытия от юнит-и приемочных испытаний . Ищите ссылки на статьи Гойко Адзича в ответе FinnNk . Adzic неоднократно спорил о тестировании бизнес-логики с помощью приемочных тестов и обхода пользовательского интерфейса.
Но некоторое количество UI-ориентированных тестов еще нужно написать . Здесь вам понадобятся некоторые практические советы, а не «не проверяйте свою бизнес-логику через пользовательский интерфейс». Я бы порекомендовал блог Патрика Уилсона-Уэлша в качестве отправной точки.
источник
Самая важная вещь при создании таких тестов после прохождения тривиального числа - это идея симметричного изменения - небольшое изменение в коде должно привести к небольшому изменению в наборе тестов.
Например, допустим, вы собрали чье-то имя с двумя текстовыми полями в 100 тестах. Если вы пишете эти тесты niavely (или, возможно, используете запись-воспроизведение), то у вас будет 100 тестов для изменения. Если вместо этого вы абстрагируете шаг «введите имя» и используете его в своих тестах вместо непосредственного использования селена, то у вас есть только 1 место для внесения изменений. От вашего контекста будет зависеть, сколько слоев абстракции вы используете, но использование абстракции будет иметь большое значение для обеспечения удобства сопровождения ваших тестов.
Вторая важная вещь - убедиться, что ваши селекторы основаны на том, что наиболее важно и наименее вероятно изменится. Иногда это будет идентификатор или класс, или это может быть текст внутри или вокруг элемента. Всегда предпочитайте самый простой селектор (например, идентификатор), но иногда для достижения этого вам придется использовать что-то вроде xpath.
Гойко Адзич имеет много полезных советов в своем блоге, когда речь заходит о такого рода тестах - посмотрите его Синус Смерти и, в частности, как его избежать .
источник
Тестирование гарантирует, что код ведет себя так, как ожидалось. Если ваши тесты ломаются на регулярной основе, то тесты либо не проверяют правильность, либо разработчики не заботятся о тестах.
Лично я считаю, что если наличие
<div>тега нарушает тест, то этот тест неоправданно строго зависит от окружающих тегов, и следует применять более мягкий подход.источник