Comments 21
Да, без качественных автоматических функциональных тестов хорошее сложное web-приложение не сделать.
Однако у оригинального Selenuim-а два недостатка: отличие языка тестов от языка клиентского кода и необходимость наличия webdriver-а для целевого браузера. И если первый недостаток давно решен в библиотеках Webdriver.io, Nightwatch, и тому подобное, позволяя писать на том же ECMA-262 ver 6+, то со вторым недостатком никаких подвижек нет.
В частности, учитывая обилие устройств, как проверить работоспособность на всевозможных смартфонах, Smart TV и тому подобное. В этом плане TestCafe нет равных, или связке TestCafe + SauceLabs — на случай если у вас нет фермы живых устройств для прогона тестов
А безголовый хром для этих целей не подходит?
а как насчет protractor.ExpectedConditions?
EC = protractor.ExpectedConditions;
form = $('.t-login-form-modal');
browser.wait(EC.or(EC.presenceOf($('.t-privat')), EC.visibilityOf(form.$('.t-alert-danger'))), 10000);
EC = protractor.ExpectedConditions;
form = $('.t-login-form-modal');
browser.wait(EC.or(EC.presenceOf($('.t-privat')), EC.visibilityOf(form.$('.t-alert-danger'))), 10000);
Мне не совсем понятно, почему анимация, которая должна отрабатывать за 800 миллисекунд, вдруг начала отрабатывать за 1200 миллисекунд и это не ошибка. Я конечно соглашусь, что писать driver.sleep(800) не хорошо, хотя бы потому, что тут захардкожена константа. Вторая проблема в том, что если у вас браузер все сделал за 200 миллисекунд, то остальные 600 миллисекунд будет просто ждать. Соглашусь, что wait с таймаутом это куда лучше, но то, что в wait так же хардкодятся константы, наверное не хорошо, по мне так лучше эти константы оговорить заранее для всего проекта и вынести в отдельное место, например:
speed.veryFast= 100;
speed.fast = 300;
speed.normal = 1000;
speed.slow = 10 * 1000;
speed.verySlow = 100 * 1000;
И в wait уже использовать эти константы:
В таком случае если скорость работы элемента не укладывается в пороговые значения, вы будете анализировать причину почему так случилось и нужно ли элемент из разряда slow переводить в verySlow или же нужно как-то оптимизировать его работу?
speed.veryFast= 100;
speed.fast = 300;
speed.normal = 1000;
speed.slow = 10 * 1000;
speed.verySlow = 100 * 1000;
И в wait уже использовать эти константы:
let iframeElem = driver.wait(
until.elementLocated(By.className('result-iframe')),
speed.slow
);В таком случае если скорость работы элемента не укладывается в пороговые значения, вы будете анализировать причину почему так случилось и нужно ли элемент из разряда slow переводить в verySlow или же нужно как-то оптимизировать его работу?
Мне не совсем понятно, почему анимация, которая должна отрабатывать за 800 миллисекунд, вдруг начала отрабатывать за 1200 миллисекунд и это не ошибка
Автор не описал один достаточно частый кейс (для мобильного тестирования) как различная среда исполнения.
К примеру, я мог для локальной машины подобрать слип в 800 миллисекунд где всё исполняется быстро, но на сервере сборки анимация проходила значительно дольше.
И заранее определить в какой среде будет исполнятся тест — едва ли выполнимая задача.
Да, но в данном случае вы говорите не «анимация должна выполняться 800 миллисекунд», а «анимация должна выполняться не более 800 миллисекунд» то есть не зависимо от того в какой среде выполняется тест, анимация должна выполняться не больше указанного времени. Все таки в большинстве случаев мы не знаем насколько загружена может быть машина пользователя, но не хотелось бы, чтобы у пользователя все работало как и задумывалось. Ну и никто не запрещал устанавливать пороговые значения в зависимости от платформы.
Вам же обьяснили, что вдруг поменялись требования или делался рефакторинг и случайно или специально разработчик увеличил время анимации. И что бы вам с ваших хардкодом не пришлось копатся и увеличивать константы, все будет четенько работать.
Если разработчик увеличит время анимации случайно, то тест упадет и разработчик исправит время анимации в приложении. Если разработчик увеличит время анимации специально, то тест упадет и разработчик исправит время анимации в тесте. Изменились требования — изменились тесты, которые эти требования проверяют. Мне кажется, что это как раз обязанность теста. По поводу увеличения констант — их не нужно увеличивать, нужно выбирать другую, они на то и константы. Если у нас элемент стал работать дольше чем «быстро», значит нам нужно или определить почему он стал работать не «быстро» или перевести в категорию «нормально» то есть изменить требования для элемента. И только в крайнем случае нужно пересмотреть выбранные константы для выбранной платформы.
Увы, это не обязанность selenium теста проверять тайминги.
Немного притормозил браузер (или сервер), анимация отыгралась медленней — тест развалился. Запустил еще раз — снова нормальный. На седьмой раз — снова развалился.
В отличии от юнит тестов в селениум тестах поведение самого браузера и сервера может быть неоднозначным, и одна из целей селениум тестирования — реагировать на такие неоднозначности адекватно, и не создавать ситуаций, в которых один и тот же тест может и упасть и пройти одновременно, пусть даже и ценой отсутствия проверок таймингов или проверок ещё чего-либо связанного с неоднозначностью.
Иначе пропадает весь смысл — нельзя доверять результату неоднозначного теста.
Немного притормозил браузер (или сервер), анимация отыгралась медленней — тест развалился. Запустил еще раз — снова нормальный. На седьмой раз — снова развалился.
В отличии от юнит тестов в селениум тестах поведение самого браузера и сервера может быть неоднозначным, и одна из целей селениум тестирования — реагировать на такие неоднозначности адекватно, и не создавать ситуаций, в которых один и тот же тест может и упасть и пройти одновременно, пусть даже и ценой отсутствия проверок таймингов или проверок ещё чего-либо связанного с неоднозначностью.
Иначе пропадает весь смысл — нельзя доверять результату неоднозначного теста.
Как я и писал выше, вы сами управляете выбором констант и можете выбрать максимально комфортные, которые будут отвечать вашим критериям стабильности. В посте у wait точно также захардкожена константа 20000. Cуть в том, что массово изменить эту константу для тестирования на менее производительном стенду не получится. Неоднозночность, даже в селениум тестах должна быть минимальной. Не плохо, когда тест падает и ошибки анализируются. Плохо, когда тесты не падают, но ошибки и неопределенно поведение происходит уже у пользователя. Вообще тайминги это некоторый контракт между тестировщиком и пользователем «Я гарантирую, что при таких условиях элемент отработает за такое время». Если вы не готовы гарантировать 1 секунду, вы можете гарантировать 100 секунд. Так или иначе используя подход указанный в посте вы тайминг пропишите, но вопрос в том, как этим таймингом вы будете управлять в дальнейшем.
Не понимаю с чем вы спорите.
Мой аргумент: Это не обязанность selenium теста проверять тайминги.
Ваш аргумент: Можно гарантировать заведомо большие тайминги.
Можно. Но это не обязанность selenium теста.
Есть глобальное значение ожидания элемента, выше которого считается, что тест упал. Его хватает с головой.
Мой аргумент: Это не обязанность selenium теста проверять тайминги.
Ваш аргумент: Можно гарантировать заведомо большие тайминги.
Можно. Но это не обязанность selenium теста.
Есть глобальное значение ожидания элемента, выше которого считается, что тест упал. Его хватает с головой.
Хорошо, а чья это обязанность проверять тайминги на анимацию, на рендеринг? Особенно если тестируете под разные платформы?
Не уверен, что есть конкретное специализированное решение, но тест таймингов однозначно должен основываться на статистике.
То есть запустил тест 1000 раз, если 900 раз попало в тайминги — хорошо. Иначе ни о какой детерменированности теста речи быть не может
То есть запустил тест 1000 раз, если 900 раз попало в тайминги — хорошо. Иначе ни о какой детерменированности теста речи быть не может
Почему тест таймингов должен основываться на статистике? Тест таймингов должен основываться на требованиях к системе, а вот требования к системе могут основываться на статистике. Например у вас в интернет магазине кнопка добавления товара в корзину стала отрабатывать на 20 секунд дольше и продажи уменьшились на 80%. Уже проведено бесчисленное количество исследований по производительности пользовательских интерфейсов. Практика показывает, что лучше это не игнорировать. По сути вы предлагаете проверить, что все работает, а я предлагаю проверить, что все работает и работает хорошо.
Я нажимал на кнопку «предпросмотр» на хабре и записал вот такие тайминги ответов:
Статистически можно высчитать, что кнопка загружается в среднем 5 секунд или 20 секунд. А по факту разница в загрузке может достигать порядка-двух из-за влияния канала между сервером и клиентом, загрузки сервера или проблем с самим клиентом.
Статистически можно высчитать, что кнопка загружается в среднем 5 секунд или 20 секунд. А по факту разница в загрузке может достигать порядка-двух из-за влияния канала между сервером и клиентом, загрузки сервера или проблем с самим клиентом.
Может кто-нибудь пояснить:
1. Зачем нам сначала ждать появление элемента в дом, а затем ждать его визибилити. Нельзя ли просто ждать визибилити? Ведь элемент не может появится на странице перед тем как попасть в DOM.
2. Вопрос по экепшену
Клик сработал во время анимации
Но ведь используя wait и ожидания visiblity мы ведь тоже можем столкнутся с этой проблемой? Или visibility condition как-то хитро устроено и определяет окончание анимации?
1. Зачем нам сначала ждать появление элемента в дом, а затем ждать его визибилити. Нельзя ли просто ждать визибилити? Ведь элемент не может появится на странице перед тем как попасть в DOM.
2. Вопрос по экепшену
System.InvalidOperationException: Element is not clickable at point (326, 792.5)
Клик сработал во время анимации
Но ведь используя wait и ожидания visiblity мы ведь тоже можем столкнутся с этой проблемой? Или visibility condition как-то хитро устроено и определяет окончание анимации?
Откровенно говоря, это проблема не только с NodeJS, а при работе с Selenium в принципе на любом языке. Пишу тесты на Codeceptuon. Столкнулся с такой лабудой, когда работал с Ajax запросами. По туториалу (одному из) ставил wait(1). Работало раз через раз. Стоило только чуть нагрузить комп, и тесты сразу вылетали. Часто ругался, что элемента какого-то нет. В итоге начал использовать функции хелперы типа waitFor(something) и проблема ушла сама собой. И тесты стали значительно быстрее.
Расскажу как я делал тестирование: селениум использовал для инжектинга js кода на страницу, который выполнял всю работу и возвращал в калбэк результат работы. Такой подход имеет такие плюсы как навешивание промисов на DOM элементы, выполнение кода в любом скопе, да и выполнение происходит быстрее, ведь тут нет множественных обращений к браузеру и пробросу результата через селениум драйвер. А по поводу driver.wait внутри это просто циклическая проверка условия с задержками. Из очевидных плюсов это возможность дебагинга кода тестов прямо в браузере через тот же инжектинг на любой сайт.
В листинге, где описывается функция waitForOpacity первый раз лишняя точка с запятой
Sign up to leave a comment.
Selenium и Node.js: пишем надёжные браузерные тесты