Зависит от количества и качества коммуникаций в команде.
В шумный адок помещение вокруг может превращать 5 человек, а может не превращать 50. Работал и в тех, и других.
Тут, на мой взгляд, принципиально важны три момента:
1) Количество свободного пространства. Сидеть друг у друга на головах некомфортно, независимо от того кабинет это или опенспейс.
2) Организация человеческих потоков. Когда мимо тебя постоянно ходят люди в опенспейсе — это не здорово. Когда у тебя над ухом хлопают дверью кабинета — точно так же не здорово.
3) Адекватные коллеги, которые понимают что вокруг работают люди, поэтому не стоит орать, петь песни и скрести ногтями по маркерной доске.
Сам предпочитаю работать в опенспейсах, сосредоточиться на задачах не мешает.
Для таких игр самая большая проблема — найти человека, который будет писать грамотные и аддиктирующие тексты.
От скриншота начал дергаться глаз и пропало всякое желание попробовать. Примитивный язык и пресные шуточки про корованы это, все таки, непозволительная роскошь для игры, в которой 99% геймплея — текст.
Да, это конечно так. И в переходах её тоже играют. А вот что бы погуглить блюз бэнды по lookalike в LastFM мне пришлось включать впн в опере. А завтра приедет товарищ майор и скажет:
— Проедемте, уважаемый, вы к запрещенной информации доступ получали.
А коты останутся без кормильца. Грустненько, в общем.
В упомянутом выше протракторе вэйты обёрнуты в работу через промиси и .then()
Из других примеров, насколько я знаю, есть из коробки в Selenide, но глубоко не изучал.
Это из того, что приходит в голову.
Я, честно говоря, в последний раз смотрел как это сделано на примере протрактора и реализовал сам. На мой взгляд, это оказалось проще, чем тянуть весь излишний фреймворк ради одной только обработки вэйтов (Protractor, изначально, тоже продвигался под предлогом того, что вэйты в ангуляре это сложно).
Инструкция «засетапь %имятехнологии%» на официальном сайте — это всегда инструкция для джуниора. Просто потому, что нужно максимально просто и прозрачно объяснить как запустить хэллоуворлд.
Это не значит, что все тесты представляют из себя этот самый хэллоуворлд.
Я согласен, что работа из коробки это замечательно, хотя зачастую работа из коробки несёт за собой пачку ограничений, которые потом приходится разгребать.
Ну, и как я уже говорил много раз, основной посыл не в том, что работа из коробки это плохо — пишите велосипеды. Основном посыл в том, что эти самые вейты много где есть, а там где нет — просто делаются самостоятельно с минимальными усилиями. Т.е. это явно не киллерфича.
Ну, окей. Это ваше право. Я, по своему опыту, столкнулся что использовать high level тестовых фреймворков совершенно не окупается и добавляет больше геморроя, нежели пользы.
В то время как «магические и суперудобные wait» представляют собой обёртку на 30 строк кода, которая делается один раз за полтора часа, с учетом кропотливого дебаггинга.
Я, ещё раз повторюсь, не говорю что «всё надо писать самому». Я про то, что тесты на webdriver-based фреймворках не лишены этих самых магических wait, а если и лишены — замечательно и без особых усилий допиливаются, вместо того, что бы пихать wait в каждый тест.
Согласен с вами полностью, такие вещи не должны писать в тестах и за это надо бить по рукам.
Более того, по моему опыту в большинстве мест, где автоматизацией занимается не джуниоры — по рукам за такое и бьют. :)
В прочем, если вы считаете, что все кто пишут автотесты с использованием WebDriver пихают waitForElement(100) после каждого действия — ваше право. Возможно для этих людей вэйты из коробки станут манной небесной и сберегут нервы тем, кто потом будет это читать.
Да, вы правы, а ещё в протракторовских тестах можно напрямую пихать wait прямо в драйвер.
Но если вы проскроллите до ответов, то увидите, что режущий глаз waitForAngular, например, оборачивается в конструкцию:
> precondition.then(function()…
И это только один из вариантов работы с вэйтами в нём, AFAIK.
Нет никакой необходимости делать обёртки на каждое действие теста.
Действие теста должно содержать, собственно, сам тест. Т.е. последовательность степов и условия его прохождения.
Ожидания, обработка несвязанных с ходом тестов падений и излишний синтаксис ассертов — вот что убирается в обёртки. Это, как раз таки, и повышает читабельность тестов.
При этом эти самые обёртки, действительно, реализуются один раз, а потом наследуются в тесты, позволяя не думать о них при написании тестовых сценариев.
И я, безусловно, не спорю — когда обёртки писать не приходится это здорово. Я к тому, что приведенное выше сравнение «Тест на TestCafe» и «Тест без оного» — немного некорректно. Т.к. в первом случае есть уже готовая обёртка в виде тестового фреймворка — тест кафе. Во втором случае фактически голый вебдрайвер «проводами наружу».
При этом если вы возьмете любой тестовый фреймворк на базе селениума (а сам селениум — не полновесный тестовый фреймворк, а только обёртка для вебдрайвера), то все эти ужасные wait'ы, на которые там выше ссылаются — всё это будет уже обёрнуто в нормальные обработчики.
Соотвественно и выглядеть это будет абсолютно точно так же, как и в случае с TestCafe.
В том же Protractor механизм «умных» wait'ов — приметивнейшая обёртка на 30 строк кода.
Рано или поздно в любой команде (и в любом тестовом фреймворке) создается простая и лаконичная обёртка для этого дела, которая, наряду с нормально выглядящими ассертами, наследуется в сами тесты.
В итоге в тесте это и там, и сям будет выглядеть как условный checkElementExists внутри которого уже будет происходить и wait и assert, просто в вашем случае оно будет сделано через await, а в любом другом тестовом фреймворке — через свой собственный зацикленный вэйтФорПейджлоад или аналог.
Естественно, нормальные wait'ы out-of-the-box это удобненько, просто, надеюсь, вы понимаете что за приведенный вами пример «не-ТестКафе кейса» близок к тому, за что бьют по рукам.
Готов поставить своего коня на то, что после получения Роскомнадзором права устанавливать тип блокировки количество блокировок по IP только возрастёт.
Ну и конечно
Всего, по информации «Роскомсвободы», России заблокирован почти 1,3 млн сайтов.
сильно печалит.
Не то, что бы на какой-то из этих сайтов я не мог зайти, но от этого не менее грустно. Слабо верится в 1.3 миллиона сайтов поддерживаемых злобными рептилоидами, распространяющими разрушающий государственный строй адалт-контент с детьми.
Скорее, как обычно, казино, онлайн библиотеки и торрент трекеры.
Ну, как минимум потому, что «попробовать и ознакомиться» — тоже требует время и ресурсов.
Дело не в том, что Selenium идеален. В нём хватает проблемных мест и костылей, во многом порожденных принципиальных подходом создателей «Мы всего лишь обёртка для WebDriver протокола», и как результат, например, невозможностью ловить и подменять реквесты\респонзы внутри работы с драйвером.
Дело в том, что создание нового инструмента «с принципиально новым подходом» предполагает, на мой взгляд, что этот инструмент устраняет какие-то by design косяки конкурента.
В противном случае это просто «мы запилили ещё один инструмент потому, что можем».
Помимо мистического «you custom selectors» — всё остальное отлично реализовано в webdriver.
встренные ассершены с retry policy
репорты
В самом вебдрайвере нет, в любом тестовом фреймворке есть. Если брать себе не голый вебдрайвер, а какой-нибудь protracktor или selenide — получите «out-of-the-box», хотя работать это будет на уже трижды обкатанном вебдрайвере.
Окей, TestCafe представляет собой более высокоуровневый фреймвор, чем голый Селениум, который изначально позиционируется как инструмент для работы с вебдрайвером, а не completed test framework.
Решений, построенных на базе селениума — воз и маленькая тележка.
Что до установки одной командой, это конечно здорово. Вместо душераздерающей связки «brew install && pip install» (в случае питона), придется использовать аж одну команду.
Правда на все машины, где будут гнаться тесты придется ставить npm.
Ответ действительно есть, хотя мне, как я уже говорил, хотелось бы видеть его в статье.
Из указанных фичей приятна только Remote. Все остальные, мягко говоря, высосаны из пальца.
По ремоут тоже есть вопросы, нужно дебажить и смотреть, как работает ваша прокся для DOM-Api и прочие велосипеды.
В целом, на мой взгляд, что бы отказаться от использования уже ставшего стандартом Вебдрайвера — нужны серьезные аргументы. Он есть в W3C (и более чем нормально поддерживается _всеми_ современными браузерами), по нему куча документации и дискассов, есть большое коммьюнити и т.д.
Извините, но «нам лень один раз засетапить тестовое окружение» — сомнительный аргумент в пользу технологии.
Выбор языка — действительно вкусовщина.
И совершенно нет никакой разницы, на каком языке работает браузер. Даже нет никакой разницы, на каком языке тестируемое приложение. Если используемый инструмент вписывается в экосистему и прост в использовании и поддержке — brew install того стоит.
Я так и не понял, а в чём грандиозное преимущество перед пресловутым Selenium?
Если смириться с JS синтаксисом (вот так мечта, получить привязку к JS вместо любого языка), то синтаксис тестов до смешения похож на селениум. Под капотом, вероятнее всего, всё тот же вебдрайвер.
Тогда, собственно, зачем?
Лично я, после фразы
Мы же собираемся продемонстрировать работу с новым open source тестовым фреймворком TestCafe, построенным на совершенно ином принципе.
ожидал увидеть более подробный рассказ того, в чем заключается «совершенно иной принцип».
Ну, как минимум «имеет больше опыта» -> уже повод платить ему больше. Особенно если он применяет этот опыт при выработке технических решений компании, а не просто ждет пока ему спустят ТЗ.
По поводу ответственности: тут всё сильно зависит от компании и процессов. Где-то ответственность несёт менеджер, потому что он менеджер. Где-то ответственность за решение несет тот человек, который компетентен принимать это решение. Где-то менеджеров вообще нет и ответственность размазана по команде ровным слоем.
В любом из этих случаев ответственность есть. Просто ты можешь получить нагоняй от топов напрямую, можешь лишиться премии, когда обиженный на тебя менеджер выдаст плохой перформанс ревью, а можешь просто получить тонну негатива, потому что из-за твоего косяка попала вся команда. Бывает по разному.
В шумный адок помещение вокруг может превращать 5 человек, а может не превращать 50. Работал и в тех, и других.
Тут, на мой взгляд, принципиально важны три момента:
1) Количество свободного пространства. Сидеть друг у друга на головах некомфортно, независимо от того кабинет это или опенспейс.
2) Организация человеческих потоков. Когда мимо тебя постоянно ходят люди в опенспейсе — это не здорово. Когда у тебя над ухом хлопают дверью кабинета — точно так же не здорово.
3) Адекватные коллеги, которые понимают что вокруг работают люди, поэтому не стоит орать, петь песни и скрести ногтями по маркерной доске.
Сам предпочитаю работать в опенспейсах, сосредоточиться на задачах не мешает.
От скриншота начал дергаться глаз и пропало всякое желание попробовать. Примитивный язык и пресные шуточки про корованы это, все таки, непозволительная роскошь для игры, в которой 99% геймплея — текст.
И?
— Проедемте, уважаемый, вы к запрещенной информации доступ получали.
А коты останутся без кормильца. Грустненько, в общем.
Из других примеров, насколько я знаю, есть из коробки в Selenide, но глубоко не изучал.
Это из того, что приходит в голову.
Я, честно говоря, в последний раз смотрел как это сделано на примере протрактора и реализовал сам. На мой взгляд, это оказалось проще, чем тянуть весь излишний фреймворк ради одной только обработки вэйтов (Protractor, изначально, тоже продвигался под предлогом того, что вэйты в ангуляре это сложно).
Флибуста, например?
Это не значит, что все тесты представляют из себя этот самый хэллоуворлд.
Я согласен, что работа из коробки это замечательно, хотя зачастую работа из коробки несёт за собой пачку ограничений, которые потом приходится разгребать.
Ну, и как я уже говорил много раз, основной посыл не в том, что работа из коробки это плохо — пишите велосипеды. Основном посыл в том, что эти самые вейты много где есть, а там где нет — просто делаются самостоятельно с минимальными усилиями. Т.е. это явно не киллерфича.
В то время как «магические и суперудобные wait» представляют собой обёртку на 30 строк кода, которая делается один раз за полтора часа, с учетом кропотливого дебаггинга.
Я, ещё раз повторюсь, не говорю что «всё надо писать самому». Я про то, что тесты на webdriver-based фреймворках не лишены этих самых магических wait, а если и лишены — замечательно и без особых усилий допиливаются, вместо того, что бы пихать wait в каждый тест.
Более того, по моему опыту в большинстве мест, где автоматизацией занимается не джуниоры — по рукам за такое и бьют. :)
В прочем, если вы считаете, что все кто пишут автотесты с использованием WebDriver пихают waitForElement(100) после каждого действия — ваше право. Возможно для этих людей вэйты из коробки станут манной небесной и сберегут нервы тем, кто потом будет это читать.
Но если вы проскроллите до ответов, то увидите, что режущий глаз waitForAngular, например, оборачивается в конструкцию:
> precondition.then(function()…
И это только один из вариантов работы с вэйтами в нём, AFAIK.
Действие теста должно содержать, собственно, сам тест. Т.е. последовательность степов и условия его прохождения.
Ожидания, обработка несвязанных с ходом тестов падений и излишний синтаксис ассертов — вот что убирается в обёртки. Это, как раз таки, и повышает читабельность тестов.
При этом эти самые обёртки, действительно, реализуются один раз, а потом наследуются в тесты, позволяя не думать о них при написании тестовых сценариев.
И я, безусловно, не спорю — когда обёртки писать не приходится это здорово. Я к тому, что приведенное выше сравнение «Тест на TestCafe» и «Тест без оного» — немного некорректно. Т.к. в первом случае есть уже готовая обёртка в виде тестового фреймворка — тест кафе. Во втором случае фактически голый вебдрайвер «проводами наружу».
При этом если вы возьмете любой тестовый фреймворк на базе селениума (а сам селениум — не полновесный тестовый фреймворк, а только обёртка для вебдрайвера), то все эти ужасные wait'ы, на которые там выше ссылаются — всё это будет уже обёрнуто в нормальные обработчики.
Соотвественно и выглядеть это будет абсолютно точно так же, как и в случае с TestCafe.
И он, к слову, прям реально заблокирован.
Рано или поздно в любой команде (и в любом тестовом фреймворке) создается простая и лаконичная обёртка для этого дела, которая, наряду с нормально выглядящими ассертами, наследуется в сами тесты.
В итоге в тесте это и там, и сям будет выглядеть как условный checkElementExists внутри которого уже будет происходить и wait и assert, просто в вашем случае оно будет сделано через await, а в любом другом тестовом фреймворке — через свой собственный зацикленный вэйтФорПейджлоад или аналог.
Естественно, нормальные wait'ы out-of-the-box это удобненько, просто, надеюсь, вы понимаете что за приведенный вами пример «не-ТестКафе кейса» близок к тому, за что бьют по рукам.
Ну и конечно
сильно печалит.
Не то, что бы на какой-то из этих сайтов я не мог зайти, но от этого не менее грустно. Слабо верится в 1.3 миллиона сайтов поддерживаемых злобными рептилоидами, распространяющими разрушающий государственный строй адалт-контент с детьми.
Скорее, как обычно, казино, онлайн библиотеки и торрент трекеры.
Дело не в том, что Selenium идеален. В нём хватает проблемных мест и костылей, во многом порожденных принципиальных подходом создателей «Мы всего лишь обёртка для WebDriver протокола», и как результат, например, невозможностью ловить и подменять реквесты\респонзы внутри работы с драйвером.
Дело в том, что создание нового инструмента «с принципиально новым подходом» предполагает, на мой взгляд, что этот инструмент устраняет какие-то by design косяки конкурента.
В противном случае это просто «мы запилили ещё один инструмент потому, что можем».
Помимо мистического «you custom selectors» — всё остальное отлично реализовано в webdriver.
В самом вебдрайвере нет, в любом тестовом фреймворке есть. Если брать себе не голый вебдрайвер, а какой-нибудь protracktor или selenide — получите «out-of-the-box», хотя работать это будет на уже трижды обкатанном вебдрайвере.
Окей, TestCafe представляет собой более высокоуровневый фреймвор, чем голый Селениум, который изначально позиционируется как инструмент для работы с вебдрайвером, а не completed test framework.
Решений, построенных на базе селениума — воз и маленькая тележка.
Что до установки одной командой, это конечно здорово. Вместо душераздерающей связки «brew install && pip install» (в случае питона), придется использовать аж одну команду.
Правда на все машины, где будут гнаться тесты придется ставить npm.
Из указанных фичей приятна только Remote. Все остальные, мягко говоря, высосаны из пальца.
По ремоут тоже есть вопросы, нужно дебажить и смотреть, как работает ваша прокся для DOM-Api и прочие велосипеды.
В целом, на мой взгляд, что бы отказаться от использования уже ставшего стандартом Вебдрайвера — нужны серьезные аргументы. Он есть в W3C (и более чем нормально поддерживается _всеми_ современными браузерами), по нему куча документации и дискассов, есть большое коммьюнити и т.д.
Извините, но «нам лень один раз засетапить тестовое окружение» — сомнительный аргумент в пользу технологии.
И совершенно нет никакой разницы, на каком языке работает браузер. Даже нет никакой разницы, на каком языке тестируемое приложение. Если используемый инструмент вписывается в экосистему и прост в использовании и поддержке — brew install того стоит.
Если смириться с JS синтаксисом (вот так мечта, получить привязку к JS вместо любого языка), то синтаксис тестов до смешения похож на селениум. Под капотом, вероятнее всего, всё тот же вебдрайвер.
Тогда, собственно, зачем?
Лично я, после фразы
ожидал увидеть более подробный рассказ того, в чем заключается «совершенно иной принцип».
По поводу ответственности: тут всё сильно зависит от компании и процессов. Где-то ответственность несёт менеджер, потому что он менеджер. Где-то ответственность за решение несет тот человек, который компетентен принимать это решение. Где-то менеджеров вообще нет и ответственность размазана по команде ровным слоем.
В любом из этих случаев ответственность есть. Просто ты можешь получить нагоняй от топов напрямую, можешь лишиться премии, когда обиженный на тебя менеджер выдаст плохой перформанс ревью, а можешь просто получить тонну негатива, потому что из-за твоего косяка попала вся команда. Бывает по разному.