Comments 21
Да, без качественных автоматических функциональных тестов хорошее сложное web-приложение не сделать.
Однако у оригинального Selenuim-а два недостатка: отличие языка тестов от языка клиентского кода и необходимость наличия webdriver-а для целевого браузера. И если первый недостаток давно решен в библиотеках Webdriver.io, Nightwatch, и тому подобное, позволяя писать на том же ECMA-262 ver 6+, то со вторым недостатком никаких подвижек нет.
В частности, учитывая обилие устройств, как проверить работоспособность на всевозможных смартфонах, Smart TV и тому подобное. В этом плане TestCafe нет равных, или связке TestCafe + SauceLabs — на случай если у вас нет фермы живых устройств для прогона тестов
+1
А безголовый хром для этих целей не подходит?
0
а как насчет 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);
0
Мне не совсем понятно, почему анимация, которая должна отрабатывать за 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 или же нужно как-то оптимизировать его работу?
+1
Мне не совсем понятно, почему анимация, которая должна отрабатывать за 800 миллисекунд, вдруг начала отрабатывать за 1200 миллисекунд и это не ошибка
Автор не описал один достаточно частый кейс (для мобильного тестирования) как различная среда исполнения.
К примеру, я мог для локальной машины подобрать слип в 800 миллисекунд где всё исполняется быстро, но на сервере сборки анимация проходила значительно дольше.
И заранее определить в какой среде будет исполнятся тест — едва ли выполнимая задача.
+1
Да, но в данном случае вы говорите не «анимация должна выполняться 800 миллисекунд», а «анимация должна выполняться не более 800 миллисекунд» то есть не зависимо от того в какой среде выполняется тест, анимация должна выполняться не больше указанного времени. Все таки в большинстве случаев мы не знаем насколько загружена может быть машина пользователя, но не хотелось бы, чтобы у пользователя все работало как и задумывалось. Ну и никто не запрещал устанавливать пороговые значения в зависимости от платформы.
+1
Вам же обьяснили, что вдруг поменялись требования или делался рефакторинг и случайно или специально разработчик увеличил время анимации. И что бы вам с ваших хардкодом не пришлось копатся и увеличивать константы, все будет четенько работать.
0
Если разработчик увеличит время анимации случайно, то тест упадет и разработчик исправит время анимации в приложении. Если разработчик увеличит время анимации специально, то тест упадет и разработчик исправит время анимации в тесте. Изменились требования — изменились тесты, которые эти требования проверяют. Мне кажется, что это как раз обязанность теста. По поводу увеличения констант — их не нужно увеличивать, нужно выбирать другую, они на то и константы. Если у нас элемент стал работать дольше чем «быстро», значит нам нужно или определить почему он стал работать не «быстро» или перевести в категорию «нормально» то есть изменить требования для элемента. И только в крайнем случае нужно пересмотреть выбранные константы для выбранной платформы.
+3
Увы, это не обязанность selenium теста проверять тайминги.
Немного притормозил браузер (или сервер), анимация отыгралась медленней — тест развалился. Запустил еще раз — снова нормальный. На седьмой раз — снова развалился.
В отличии от юнит тестов в селениум тестах поведение самого браузера и сервера может быть неоднозначным, и одна из целей селениум тестирования — реагировать на такие неоднозначности адекватно, и не создавать ситуаций, в которых один и тот же тест может и упасть и пройти одновременно, пусть даже и ценой отсутствия проверок таймингов или проверок ещё чего-либо связанного с неоднозначностью.
Иначе пропадает весь смысл — нельзя доверять результату неоднозначного теста.
Немного притормозил браузер (или сервер), анимация отыгралась медленней — тест развалился. Запустил еще раз — снова нормальный. На седьмой раз — снова развалился.
В отличии от юнит тестов в селениум тестах поведение самого браузера и сервера может быть неоднозначным, и одна из целей селениум тестирования — реагировать на такие неоднозначности адекватно, и не создавать ситуаций, в которых один и тот же тест может и упасть и пройти одновременно, пусть даже и ценой отсутствия проверок таймингов или проверок ещё чего-либо связанного с неоднозначностью.
Иначе пропадает весь смысл — нельзя доверять результату неоднозначного теста.
0
Как я и писал выше, вы сами управляете выбором констант и можете выбрать максимально комфортные, которые будут отвечать вашим критериям стабильности. В посте у wait точно также захардкожена константа 20000. Cуть в том, что массово изменить эту константу для тестирования на менее производительном стенду не получится. Неоднозночность, даже в селениум тестах должна быть минимальной. Не плохо, когда тест падает и ошибки анализируются. Плохо, когда тесты не падают, но ошибки и неопределенно поведение происходит уже у пользователя. Вообще тайминги это некоторый контракт между тестировщиком и пользователем «Я гарантирую, что при таких условиях элемент отработает за такое время». Если вы не готовы гарантировать 1 секунду, вы можете гарантировать 100 секунд. Так или иначе используя подход указанный в посте вы тайминг пропишите, но вопрос в том, как этим таймингом вы будете управлять в дальнейшем.
0
Не понимаю с чем вы спорите.
Мой аргумент: Это не обязанность selenium теста проверять тайминги.
Ваш аргумент: Можно гарантировать заведомо большие тайминги.
Можно. Но это не обязанность selenium теста.
Есть глобальное значение ожидания элемента, выше которого считается, что тест упал. Его хватает с головой.
Мой аргумент: Это не обязанность selenium теста проверять тайминги.
Ваш аргумент: Можно гарантировать заведомо большие тайминги.
Можно. Но это не обязанность selenium теста.
Есть глобальное значение ожидания элемента, выше которого считается, что тест упал. Его хватает с головой.
0
Хорошо, а чья это обязанность проверять тайминги на анимацию, на рендеринг? Особенно если тестируете под разные платформы?
0
Не уверен, что есть конкретное специализированное решение, но тест таймингов однозначно должен основываться на статистике.
То есть запустил тест 1000 раз, если 900 раз попало в тайминги — хорошо. Иначе ни о какой детерменированности теста речи быть не может
То есть запустил тест 1000 раз, если 900 раз попало в тайминги — хорошо. Иначе ни о какой детерменированности теста речи быть не может
0
Почему тест таймингов должен основываться на статистике? Тест таймингов должен основываться на требованиях к системе, а вот требования к системе могут основываться на статистике. Например у вас в интернет магазине кнопка добавления товара в корзину стала отрабатывать на 20 секунд дольше и продажи уменьшились на 80%. Уже проведено бесчисленное количество исследований по производительности пользовательских интерфейсов. Практика показывает, что лучше это не игнорировать. По сути вы предлагаете проверить, что все работает, а я предлагаю проверить, что все работает и работает хорошо.
0
Я нажимал на кнопку «предпросмотр» на хабре и записал вот такие тайминги ответов:
Статистически можно высчитать, что кнопка загружается в среднем 5 секунд или 20 секунд. А по факту разница в загрузке может достигать порядка-двух из-за влияния канала между сервером и клиентом, загрузки сервера или проблем с самим клиентом.
Статистически можно высчитать, что кнопка загружается в среднем 5 секунд или 20 секунд. А по факту разница в загрузке может достигать порядка-двух из-за влияния канала между сервером и клиентом, загрузки сервера или проблем с самим клиентом.
0
Может кто-нибудь пояснить:
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 как-то хитро устроено и определяет окончание анимации?
+2
Откровенно говоря, это проблема не только с NodeJS, а при работе с Selenium в принципе на любом языке. Пишу тесты на Codeceptuon. Столкнулся с такой лабудой, когда работал с Ajax запросами. По туториалу (одному из) ставил wait(1). Работало раз через раз. Стоило только чуть нагрузить комп, и тесты сразу вылетали. Часто ругался, что элемента какого-то нет. В итоге начал использовать функции хелперы типа waitFor(something) и проблема ушла сама собой. И тесты стали значительно быстрее.
0
Расскажу как я делал тестирование: селениум использовал для инжектинга js кода на страницу, который выполнял всю работу и возвращал в калбэк результат работы. Такой подход имеет такие плюсы как навешивание промисов на DOM элементы, выполнение кода в любом скопе, да и выполнение происходит быстрее, ведь тут нет множественных обращений к браузеру и пробросу результата через селениум драйвер. А по поводу driver.wait внутри это просто циклическая проверка условия с задержками. Из очевидных плюсов это возможность дебагинга кода тестов прямо в браузере через тот же инжектинг на любой сайт.
0
В листинге, где описывается функция waitForOpacity первый раз лишняя точка с запятой
0
Sign up to leave a comment.
Selenium и Node.js: пишем надёжные браузерные тесты