testomat.io управление авто тестамиКак вы это представляете, что действия не будет?
Да есть множество возможных вариантов начиная с упомянутого выше “элемент виден но не кликабелен ибо перекрыт чем либо”, продолжая “ошибка в HTML самого элемента”, дальше можно фантазировать и вспоминать случаи из практики но это в данном контексте абсолютно не важно так как сценарий №2 отличается от того что будет делать в такой ситуации пользователь, а значит не является валидным как тест пользовательского интерфейса. Если вы тестируете пользовательский интерфейс то должны в точности следовать пользовательским сценариям что бы получать те же результаты которые получат реальные пользователи. О таком же подходе писали и сами создатели Webdrivera в ответах на многочисленные просьбы расширить функционал Selenium для работы с HTTP заголовками. В своем ответе в багтреккере они писали нечто вроде … да зачем же я фантазировать буду - точно написали “We will not be adding this feature to the WebDriver API as it falls outside of our current scope (emulating user actions)”
3 лайка
Оба варианта мне показались сомнительными.
Первый противоречит одному из основных принципов тестирования (см. exhaustive testing). Вы ведь при переходе по ссылкам наверняка всегда попадаете в одну и ту же область приложения, так? Разве нельзя выделить классы эквивалентности для покрытия основных кейсов? Или линки ведут на внешние ресурсы? Тут тогда вообще нечего проверять, кроме как на битость.
Согласен с выше указанным поинтом относительно приведения системы в нужное состояние для тестирования. Вы должны проверять конкретные вещи, а не все подряд. Ссылки ведь не просто так там появились? Наверняка для их появления были выполнены определенные действия с приложением. Что мешает вам подготовить данные таким образом, чтобы переход осуществлялся исключительно по тем сущностям, что вы сами создали? Лень создавать вручную? Генерьте скриптами, готовьте дампы и т.п.
Второй поинт (его заключительная часть) скорее направлен на url validation, нежели проверку бизнес логики. Битые ссылки можно чекнуть гораздо менее ресурсо затратным способом, без использования WebDriver'а.
Если вам действительно нужно проверить функционал (ваш внутренний), то более логичным было бы:
- подготовить сущности;
- отфильтровать по заранее известному критерию в гриде;
- проверить наличие / отсутствие заранее известных линок (или их масок);
- перейти и проверить валидность того, что должно в итоге отобразиться;
- повторить в соответствии со сформированными эквивалентными разбиениями.
9 лайков
Похоже, это самый лучший ответ из представленных сегодня.
Update: Единственное - это такое идеальное тестирование, аж прям к вам на работу захотелось.
Для проверки линков обычно Xenu Link используют, потому что ситуация зачастую редкая.
эта тема очень похожа на пример почему нужно Как автоматизатору прокачать скилы мануального тестирования - #10 от пользователя fujif23 , а не бросаться на амбразуру
Хотелось бы почитать более развернутый пост. Что вы имеете в виду? (мне смысл вашего поста кажется достаточно странным, но, возможно, я неправильно интерпретировала его, поэтому пока воздержусь от комментариев)
Совершенно однозначно, второй вариант лучше. Он экономит время. А первый тратит ОГРОМНУЮ КУЧУ времени, не добавляя никакой ценности.
Более того, я бы предложил третий вариант.
- ВСЕ ссылки проверять через простой http запрос. Незачем тратить время даже на первый запрос через вебдрайвер.
- не нужно полностью считывать респонс с этих ссылок. Достаточно только проверить, что они возвращают код 200 (ну или редирект на 200).
2 лайка
Второй вариант действительно экономит время.
Однако же, если мы автоматизируем пользовательские сценарии, мы должны, как упоминалось выше, все же имитировать действия пользователя. Пользователь не может отправить гет-запрос,игнорируя нажатие кнопки сабмита, и используя второй вариант, мы выкидываем из сценария как минимум один шаг, что, как опять же упоминалось выше, может показать зеленый тест при наличии реального бага.
Все же я за разграничение юнит-тестов и автоматизации пользовательских сценариев. Юнит-тесты и программисты напишут прекрасно, у нас же цель другая.
Кстати, в моем примере - даже если страницы не существует и показывается ошибка 404, response.code все равно 200. Поэтому только вариант с полным парсингом. PS: сайт наружу не смотрит, поэтому простительно.
А это вы должны зарегистрировать как багу вашим разработчикам.
Если страница не найдена, она должна возвращать код 404.
Если она возвращает 200 - это бага.
1 лайк
А по-вашему, это нормальный пользовательский сценарий - прокликать 200 ссылок?
Хоть один пользователь так делает?
Если уж вам так принципиально - ок, можно сделать один запрос через браузер. Но не все 200.
Я бы немного с другой стороны подошёл к проблеме. 1. Проверить отдельно отработку фильтра по граничным значения c проверкой href у появившихся ссылок. 2. Проверить функцию генерации этих ссылок так же по граничным значениям. По-моему, это займёт меньше времени и будет большее покрытие тестами. + не будет зависимости от количества ссылок, может ссылок в процессе развития проекта будет 10000+, не писать же тесты для каждой ссылки
Сегодня было принято решение, что прокликивать и даже дергать запросами все ссылки в списке не нужно. Оптимальный вариант, на котором сошлись - брать рандомную одну и проверять вебдрайвером. Кроме того, в целом, имеется список функционала, баги в котором являются критическими, позиция руководства - проверка данного функционала - только имитация действий пользователя (что я лично поддерживаю, у нас именно UI-сценарии, юнит-тестов и без нас хватает). А вот где-то в некритичных местах - имеет право на жизнь проверка с гет-запросами и прочими “не-юзер” вещами.
Вот так разрешился спор. И нашим, и вашим, и оптимизация тут же.
А как бы вы о этой баге узнали, если код ответа 200. Вручную при наличии автотестов туда редко кто ходить будет.
Так и с помощью селениума Вы бы не узнали - он же вообще не позволяет проверять http status. А на контент этих страниц должны быть свои тесты.
Кажется понял. Принцип один тест - одна проверка? Иногда просто удобней проверять несколько вещей в рамках одного теста. Но это уже спор о вкусовщине и различных подходах в тест-дизайне.
P.S. если бы тест проверял статус, а затем содержимое , то мы бы увидели ошибку. Статус положительный, а содержания нет. А так бы пришлось два теста на одну страницу лепить и все равно не обнаружили бы расхождения, т.к. вряд ли бы вспомнили, что тесты связаны. Get бы успешно дал код 200 и мы бы про него забыли, а по факту там 404.
Какой у всех все же разный подход.
Принцип “один тест - одна проверка” иногда очень неудобен.
Мы, при проверке ссылок, обычно проверяем и то, что открылась правильная страница, и то, что контент какой-то ключевой соответствует. Две проверки в одном тесте, да. Но ведь даже в Cucumber для этого специально есть And, так что, “должно”, “не должно” - это тоже довольно спорно.
1 лайк
То есть я так понимаю задачи проверить именно кликабельность ссылок не стоит?
1 тест = 1 проверка - это явно не для e2e тестов. Иначе их рано или поздно станет больше, чем unit. А total execution time будет измеряться неделями.
3 лайка