Global Shared libraries отпало, т.к. это нарушало саму идею, что весь код хранится целостно в одном месте (получается часть приходит из Git, часть добавлена руками в Jenkins). По поводу Filesystem SCM были не в курсе, в ближайшее время опробуем.
Наиболее интересно звучит Folder-level libraries. Но в статье есть лишь упоминание, без конкретики и примеров.
На данный момент всю логику стараемся вынести в shell скрипты наподобии:
clean-test-package
describe-environment
deploy-to-cloud
В идеале в Declarative Pipeline было бы полезно и удобно иметь возможность организовывать набор из стэйджев — и потом ссылаться на различные стейджи в тех пайплайнах где это необходимо. К примеру так:
Если вдруг будет дефицит вопросов (вряд ли конечно), то вот те, которые интересуют нашу команду:
— как разработчики Declarative Pipeline видят в будущем структуризацию groovy кода? Интересует как собираются решать текущие трудности с переиспользованием разных элементов (pipeline, stage, step) в нескольких разных пайплайнах. Текущее решение, использующее чекаут Git репозитория для подключения библиотек, многими воспринимается как неудобное и усложненное.
— подходит ли Pipeline концепт к мультирепозиторным проектам? Пример — когда модули одного проекта разбросаны по разным Git репозиториям, но при этом у них общий CI и CD. Или же Pipeline концептуально настаивает на монорепозиториях?
— есть ли планы более плотной интеграции с Gradle? Вопрос в связи с тем, что теперь по сути в репозитории появился еще один build-script файл (jenkins file). Но задача/ответственность по сути близка к скриптам Gradle и Maven.
— есть ли планы разработки плагинов для Intellij Idea с полноценной поддержкой Jenkinsfile?
Эти вопросы для нас очень важны, так как Pipeline с одной стороны серьезно отличается от традиционного подхода, с другой стороны весьма активно разрабатывается и быстро изменяется, эволюционирует. Знать в каком направлении планируют развивать продукт и решение разработчики — может помочь минимизировать риски выбора неверных дизайнерских решений на данном этапе для тех, кто уже начал миграцию.
Оценивая по себе, предполагаю, что большинство не может туда даже зайти. Это действо определенно заставляет собрать волю в кулак и еще раз найти свой снилс и вспомнить наконец пароль. Чаще всего, возникает желание не прорваться туда любой ценой, а желание внести свою маленькую лепту — в свои свободные в перерыве на работе пять минут. А как только осознаешь, что только на авторизацию потребуется неизвестное количество времени — сразу откладываешь и думаешь — в следующий раз.
Те инициативы, что набрали 100% — шли как раз в волне хорошего освещения в СМИ и продвижения в блогосферах. Это была очень мотивирующая сила. Выразить свое единство во мнении с остальными, твердость своих намерений, поддержать общую позицию. Более того — некоторые инициативы исходили от авторитетных личностей и сразу в подготовленном виде. Было очень подробное описание к чему они могут привести.
В случае с инициативой исходящей от неизвестного мне гражданина, я сразу же рассматриваю ее в том числе и как вероятную провокацию.
По поводу бесполезности — не соглашусь. Польза в индикации отношения к нам как минимум. В официальном игнорировании требований, не важно под какими предлогами. Теперь больше возможности говорить об этом как о факте.
Если точнее, то регистрировался на госуслугах, когда никакого РОИ вообще еще и не было.
А вообще неэффективность этого ресурса была прогнозируема. Депутатам и прочим власть имущим итак никто не мешал собирать инициативы от граждан и проводить их через принятие законов. Очевидно, что это не область их интересов.
Другое дело, что мы — не должны игнорировать этот ресурс — т.к. это официальный инструмент для такой задачи. Подача сигнала и его обработка — разные вещи. На нас ответственность — подавать сигнал. Да и сама концепция у ресурса очень правильная в теории. Хромает именно реализация.
Но вообще говоря, эффективность и вовлеченность граждан можно было бы повысить, если бы был ресурс, с профессиональными юристами, экономистами, управленцами и прочими инициативными специалистами разных областей — где общество могло бы обозначать проблему, а вот такие специалисты — могли бы подготовить грамотное ее описание и решение и далее уже регистрировать это как инициативу на РОИ.
Сейчас понял в чем была проблема. Я тогда о ней еще не знал, поэтому не запомнил. Практически гарантированно, что проблема была в несоответствии версии вебдрайвера и версии браузера firefox. Только что опять напоролся, после обновления firefox.
Во-первых, проблему нужно решать до ее возникновения. Такой код просто не должен уйти в систему контроля версии.
Самый позитивный и комфортный опыт моей работы был в команде, где принято проводить код-ревью для абсолютно каждого коммита. В дополнении к этому, были достаточно строгие требования к форматированию кода, названию методов, классов, переменных. С течением времени, стиль написания кода у всех участников команды стал схожий (насколько я ощущаю — достаточно высокий уровень, хотя это субъективное восприятие). Если возникал спорный вопрос — как делать правильно — мы единожды его обсуждали, могли потратить довольно много времени на это. После чего принимали единственное взвешенное решение (не важно кто как привык) и далее договаривались придерживаться именно такого подхода.
Так же этому всему сопутствовал подход — не указывать на сам факт чьей-то вины, но искать хозяина кода. Главное — искать ошибку, недочет, уязвимость, плохой стиль — объяснять (аналогично обучению) почему так делать нельзя, приводить примеры к чему это может привести и показывать как делать надо. Т.е. самое главное — обмен опытом, открытая дружественная дискуссия, наша задача — саморазвитие и совершенствование, все совершают ошибки и это нормально.
Такая атмосфера очень полезна и положительно влияет на успехи команды. Все члены команды открыты друг другу и не пытаются скрыть что-либо от остальных, не пытаются защищаться, не пытаются нападать — нет агрессии. Это не война и тут нет врагов.
Я, к сожалению, работал и в другом коллективе. Где за высказанную в общий чат критику по коду, весь чат ополчился против бедняги. Работа в таком коллективе вызывала только ненависть. Абсолютная деструкция и постоянные подставы среди участников команды.
Будет радостно, если в ближайшем будущем в результате подобных разработок в океане начнет действовать экологическая армия ботов, способных собирать мусор и отходы, засоряющие океаны — в локациях, где их удобно будет извлечь.
Нашел в старых логах сообщение падавшей ошибки:
Caused by: org.openqa.selenium.InvalidElementStateException: Element must not be hidden, disabled or read-only
При этом элемент отображался, был виден и не имел никаких атрибутов, скрывающих его.
Прошу прощения что задержался с ответом — был отпуск :)
Сделал демку, webElement.clear() — срабатывает. Попробовал отработать его в собственном проекте — тоже срабатывает.
На данный момент рабочая версия webdriver'а — 2.30.0.
В качестве webElement выступает элемент input с type=«text»
Возможно проблема с этим методом была в версиях, на которых я стартовал разработку тестов — 2.24, 2.25, 2.26, т.к. от этого метода я отказался в начале разработки.
Вообщем странная ситуация, я точно помню что выпадала ошибка и точно помню, что находил на stackoverflow комментарии о проблеме с этим методом. К сожалению в данный момент мало времени, чтобы эксперементировать, но если оно появится — попробую воспроизвести на старых версиях.
По поводу Thread.sleep(1000);
Я вспомнил с чем связан такой варварский подход.
Суть в том, что это пауза не только для того, чтобы элемент появился в DOM модели и стал доступен для выборки. Суть в том, что элементу еще необходимо успеть отрисоваться, перед тем как с ним начнут далее взаимодействовать (click()). Я пробовал делать перед действием проверку isDisplayed(), но с огромной постоянностью тесты падали на начальном этапе с сообщениями, что элемент не доступен для действия click, так как невидим. Т.е. эта проверка возвращала true еще до того, как элемент полностью отрисуется. Видимо, она возвращает true, как только нет никаких причин считать элемент невидимым с точки зрения значений его стилей, атрибутов, а не визуального отображения, но это догадка.
После поиска альтернативного решения я попробовал все возможные ExpectedConditions, обернутые в WebDriverWait с достаточными таймаутами и периодами, чтобы элемент успел отрисоваться и даже больше. Но по сути это всего лишь обертка над тем же самым isDisplayed. Элемент возвращается неотрисованным.
Делать свою реализацию, которая пытается в таком цикле выполнять действие, пока не добьется успеха, а все исключения ловить и игнорировать — мне показалось тоже грязным вариантом, который при этом не достаточно понятен и читаем, в ситуации если требуется передать код на поддержку третьим лицам.
С другой стороны… хм, можно реализовать WebDriverWait, который не ждет, когда элемент будет отрисован, а просто ждет указанное время — аналогично и взамен Thread.sleep(1000);
Если делать подобные захардкоженые паузы — в принципе плохо, не суть важно будь это спящий поток или цикл с таймингом — дайте плз знать.
Вообщем, у меня нет ответа на вопрос, как это сделать правильно. Если знаете выход — отпишите плз, т.к. все варианты на stackoverflow я уже перечитал.
Вы не могли бы опубликовать пример, на котором у вас метод не работает.
Вы имеете в виду webElement.clear()? или выделение текста и его последующее замещение?
Ок, проверю еще раз оба варианта и выложу результаты, дабы не было заблуждений, но уже завтра :)
Принцип простой — в одной сети должны быть Selenium Hub и одна или несколько Selenium Node. По сути различия в структуре нет — это один и тот же jar файл, запущенный в разных режимах. (к примеру такой: selenium-server-standalone-2.30.0.jar).
Selenium Hub — точка, куда необходимо отправлять запрос на выполнение теста. Хаб распределяет задачи между своими нодами (исполнителями), учитывая наличие у них свободных слотов и сравнивая соответствия (capabilities) пришедшего теста и свободного слота. Если подходящий слот не найден — тест будет оборван.
Настройка всей сетки проста и не занимает много времени. Для профилирования тестов по отдельным браузерам надо создавать инстансы вебдрайверов — соответствующих этим браузерам, все они являются расширениями RemoteWebDriver'а.
Важно держать в уме, что параллельные тесты будут одновременно менять данные, тем самым есть огромная вероятность, что тестирование одного и того же инстанса веб-клиента — не принесет успеха, будет постоянно падать с ошибками. Нужно либо предоставлять набор таких инстансов (включая серверную часть — целиком воспроизводить всю инфраструктуру) для каждой ноды, либо, если клиент это поддерживает — разделять зоны в зависимости от разных аккаунтов. Еще можно пытаться составить матрицу методов, которые гарантированно не влияют друг на друга даже в пессимистичных сценариях и полагаясь на это гонять их параллельно.
Я в конечном итоге пришел к функциональным слоям:
— абстрактный рутовый слой, содержащий всю низкоуровневую работу с веб-драйвером (построение, обертки над методами WebDriver API)
— слой навигации (просто набор методов goToMainPage, goToSearchTab)
— слой частых действий или действий, которые требуются более чем в одном тесте
— слой локаторов — огромный, строк на 300, справочник констант с объектами типа By. Есть желание сделать его вообще в виде внешнего property файла, но это уже детали.
Пока не могу сказать, насколько это удачное решение — видно станет, когда мне предстоит передать этот код на поддержку заказчику :)))
В самой статье я постарался описать те разочарования, которые ожидают разработчика, впервые столкнувшегося с подобной задачей. Так что тут вполне могут быть описаны наивные вещи.
Странно что этот базовый принцип вы открыли для себя с такой болью.
Мне стало больно скорее от того, что, конкретно в случае с Selenium, возможность «подчистить», в большинстве случаев, сводится к дополнительным шагам, аналогичным по природе тестовым действиям. А такие действия уязвимы для описанных проблем. Т.е. большинство раз тест отработает, но могут случиться исключения. Более того, такие неэффективные методы приносят дополнительные достаточно существенные временные затраты. Вот, видимо, такая ненадежность меня и удивила, во время первого опыта.
Откройте для себя Developer tools различных браузеров и не мучайтесь с этим «IDE»
Именно к этому я и пришел. Большую часть времени разработка проходит в процессе подбора XPath ключей, использовании различных плагинов, файр-багов и обычной JS консоли.
WebDriver далеко не идеален, однако он вполне юзабелен. И я бы не стал говорить о том что вы «эффективно использовали» Selenium после фразы «больше всего страшно, что тестируемый web-клиент будет видоизменен». ;)
На своем уровне познания Selenium я не смог придумать, как, не изменяя исходные кода веб-клиента, отвязать процесс тестирования от жестких завязок на структуру элементов. Я стараюсь их минимизировать, но идеальная ситуация, когда к любому элементу можно обратиться по уникальному ID. К сожалению, для меня это невозможно. По крайней мере, я не понимаю как это сделать :)
С библиотеками пробовали руководствоваться этой статьей:
https://jenkins.io/doc/book/pipeline/shared-libraries/
Global Shared libraries отпало, т.к. это нарушало саму идею, что весь код хранится целостно в одном месте (получается часть приходит из Git, часть добавлена руками в Jenkins). По поводу Filesystem SCM были не в курсе, в ближайшее время опробуем.
Наиболее интересно звучит Folder-level libraries. Но в статье есть лишь упоминание, без конкретики и примеров.
На данный момент всю логику стараемся вынести в shell скрипты наподобии:
clean-test-package
describe-environment
deploy-to-cloud
В идеале в Declarative Pipeline было бы полезно и удобно иметь возможность организовывать набор из стэйджев — и потом ссылаться на различные стейджи в тех пайплайнах где это необходимо. К примеру так:
pipeline {...
stage(describe-environment)
stage(clean-test-package)
stage(deploy-to-cloud)
...
}
Если вдруг будет дефицит вопросов (вряд ли конечно), то вот те, которые интересуют нашу команду:
— как разработчики Declarative Pipeline видят в будущем структуризацию groovy кода? Интересует как собираются решать текущие трудности с переиспользованием разных элементов (pipeline, stage, step) в нескольких разных пайплайнах. Текущее решение, использующее чекаут Git репозитория для подключения библиотек, многими воспринимается как неудобное и усложненное.
— подходит ли Pipeline концепт к мультирепозиторным проектам? Пример — когда модули одного проекта разбросаны по разным Git репозиториям, но при этом у них общий CI и CD. Или же Pipeline концептуально настаивает на монорепозиториях?
— есть ли планы более плотной интеграции с Gradle? Вопрос в связи с тем, что теперь по сути в репозитории появился еще один build-script файл (jenkins file). Но задача/ответственность по сути близка к скриптам Gradle и Maven.
— есть ли планы разработки плагинов для Intellij Idea с полноценной поддержкой Jenkinsfile?
Эти вопросы для нас очень важны, так как Pipeline с одной стороны серьезно отличается от традиционного подхода, с другой стороны весьма активно разрабатывается и быстро изменяется, эволюционирует. Знать в каком направлении планируют развивать продукт и решение разработчики — может помочь минимизировать риски выбора неверных дизайнерских решений на данном этапе для тех, кто уже начал миграцию.
Сделайте онлайн трансляцию пожалуйста если есть возможность!
Поправьте пожалуйста ссылку на Trusted Advisor. Сейчас она ведет к 404 и выглядит так:
aws.amazon.com/ru/premiumsupport/trustedadvisor)?
Те инициативы, что набрали 100% — шли как раз в волне хорошего освещения в СМИ и продвижения в блогосферах. Это была очень мотивирующая сила. Выразить свое единство во мнении с остальными, твердость своих намерений, поддержать общую позицию. Более того — некоторые инициативы исходили от авторитетных личностей и сразу в подготовленном виде. Было очень подробное описание к чему они могут привести.
В случае с инициативой исходящей от неизвестного мне гражданина, я сразу же рассматриваю ее в том числе и как вероятную провокацию.
По поводу бесполезности — не соглашусь. Польза в индикации отношения к нам как минимум. В официальном игнорировании требований, не важно под какими предлогами. Теперь больше возможности говорить об этом как о факте.
А вообще неэффективность этого ресурса была прогнозируема. Депутатам и прочим власть имущим итак никто не мешал собирать инициативы от граждан и проводить их через принятие законов. Очевидно, что это не область их интересов.
Другое дело, что мы — не должны игнорировать этот ресурс — т.к. это официальный инструмент для такой задачи. Подача сигнала и его обработка — разные вещи. На нас ответственность — подавать сигнал. Да и сама концепция у ресурса очень правильная в теории. Хромает именно реализация.
Но вообще говоря, эффективность и вовлеченность граждан можно было бы повысить, если бы был ресурс, с профессиональными юристами, экономистами, управленцами и прочими инициативными специалистами разных областей — где общество могло бы обозначать проблему, а вот такие специалисты — могли бы подготовить грамотное ее описание и решение и далее уже регистрировать это как инициативу на РОИ.
Самый позитивный и комфортный опыт моей работы был в команде, где принято проводить код-ревью для абсолютно каждого коммита. В дополнении к этому, были достаточно строгие требования к форматированию кода, названию методов, классов, переменных. С течением времени, стиль написания кода у всех участников команды стал схожий (насколько я ощущаю — достаточно высокий уровень, хотя это субъективное восприятие). Если возникал спорный вопрос — как делать правильно — мы единожды его обсуждали, могли потратить довольно много времени на это. После чего принимали единственное взвешенное решение (не важно кто как привык) и далее договаривались придерживаться именно такого подхода.
Так же этому всему сопутствовал подход — не указывать на сам факт чьей-то вины, но искать хозяина кода. Главное — искать ошибку, недочет, уязвимость, плохой стиль — объяснять (аналогично обучению) почему так делать нельзя, приводить примеры к чему это может привести и показывать как делать надо. Т.е. самое главное — обмен опытом, открытая дружественная дискуссия, наша задача — саморазвитие и совершенствование, все совершают ошибки и это нормально.
Такая атмосфера очень полезна и положительно влияет на успехи команды. Все члены команды открыты друг другу и не пытаются скрыть что-либо от остальных, не пытаются защищаться, не пытаются нападать — нет агрессии. Это не война и тут нет врагов.
Я, к сожалению, работал и в другом коллективе. Где за высказанную в общий чат критику по коду, весь чат ополчился против бедняги. Работа в таком коллективе вызывала только ненависть. Абсолютная деструкция и постоянные подставы среди участников команды.
Wall-e, мы идем к тебе! :)
Caused by: org.openqa.selenium.InvalidElementStateException: Element must not be hidden, disabled or read-only
При этом элемент отображался, был виден и не имел никаких атрибутов, скрывающих его.
Но, повторюсь, лучше проверить на старых версиях
Сделал демку, webElement.clear() — срабатывает. Попробовал отработать его в собственном проекте — тоже срабатывает.
На данный момент рабочая версия webdriver'а — 2.30.0.
В качестве webElement выступает элемент input с type=«text»
Возможно проблема с этим методом была в версиях, на которых я стартовал разработку тестов — 2.24, 2.25, 2.26, т.к. от этого метода я отказался в начале разработки.
Вообщем странная ситуация, я точно помню что выпадала ошибка и точно помню, что находил на stackoverflow комментарии о проблеме с этим методом. К сожалению в данный момент мало времени, чтобы эксперементировать, но если оно появится — попробую воспроизвести на старых версиях.
Я вспомнил с чем связан такой варварский подход.
Суть в том, что это пауза не только для того, чтобы элемент появился в DOM модели и стал доступен для выборки. Суть в том, что элементу еще необходимо успеть отрисоваться, перед тем как с ним начнут далее взаимодействовать (click()). Я пробовал делать перед действием проверку isDisplayed(), но с огромной постоянностью тесты падали на начальном этапе с сообщениями, что элемент не доступен для действия click, так как невидим. Т.е. эта проверка возвращала true еще до того, как элемент полностью отрисуется. Видимо, она возвращает true, как только нет никаких причин считать элемент невидимым с точки зрения значений его стилей, атрибутов, а не визуального отображения, но это догадка.
После поиска альтернативного решения я попробовал все возможные ExpectedConditions, обернутые в WebDriverWait с достаточными таймаутами и периодами, чтобы элемент успел отрисоваться и даже больше. Но по сути это всего лишь обертка над тем же самым isDisplayed. Элемент возвращается неотрисованным.
Делать свою реализацию, которая пытается в таком цикле выполнять действие, пока не добьется успеха, а все исключения ловить и игнорировать — мне показалось тоже грязным вариантом, который при этом не достаточно понятен и читаем, в ситуации если требуется передать код на поддержку третьим лицам.
С другой стороны… хм, можно реализовать WebDriverWait, который не ждет, когда элемент будет отрисован, а просто ждет указанное время — аналогично и взамен Thread.sleep(1000);
Если делать подобные захардкоженые паузы — в принципе плохо, не суть важно будь это спящий поток или цикл с таймингом — дайте плз знать.
Вообщем, у меня нет ответа на вопрос, как это сделать правильно. Если знаете выход — отпишите плз, т.к. все варианты на stackoverflow я уже перечитал.
Вы имеете в виду webElement.clear()? или выделение текста и его последующее замещение?
Ок, проверю еще раз оба варианта и выложу результаты, дабы не было заблуждений, но уже завтра :)
code.google.com/p/selenium/wiki/Grid2
Принцип простой — в одной сети должны быть Selenium Hub и одна или несколько Selenium Node. По сути различия в структуре нет — это один и тот же jar файл, запущенный в разных режимах. (к примеру такой: selenium-server-standalone-2.30.0.jar).
Selenium Hub — точка, куда необходимо отправлять запрос на выполнение теста. Хаб распределяет задачи между своими нодами (исполнителями), учитывая наличие у них свободных слотов и сравнивая соответствия (capabilities) пришедшего теста и свободного слота. Если подходящий слот не найден — тест будет оборван.
Настройка всей сетки проста и не занимает много времени. Для профилирования тестов по отдельным браузерам надо создавать инстансы вебдрайверов — соответствующих этим браузерам, все они являются расширениями RemoteWebDriver'а.
Важно держать в уме, что параллельные тесты будут одновременно менять данные, тем самым есть огромная вероятность, что тестирование одного и того же инстанса веб-клиента — не принесет успеха, будет постоянно падать с ошибками. Нужно либо предоставлять набор таких инстансов (включая серверную часть — целиком воспроизводить всю инфраструктуру) для каждой ноды, либо, если клиент это поддерживает — разделять зоны в зависимости от разных аккаунтов. Еще можно пытаться составить матрицу методов, которые гарантированно не влияют друг на друга даже в пессимистичных сценариях и полагаясь на это гонять их параллельно.
— абстрактный рутовый слой, содержащий всю низкоуровневую работу с веб-драйвером (построение, обертки над методами WebDriver API)
— слой навигации (просто набор методов goToMainPage, goToSearchTab)
— слой частых действий или действий, которые требуются более чем в одном тесте
— слой локаторов — огромный, строк на 300, справочник констант с объектами типа By. Есть желание сделать его вообще в виде внешнего property файла, но это уже детали.
Пока не могу сказать, насколько это удачное решение — видно станет, когда мне предстоит передать этот код на поддержку заказчику :)))
Мне стало больно скорее от того, что, конкретно в случае с Selenium, возможность «подчистить», в большинстве случаев, сводится к дополнительным шагам, аналогичным по природе тестовым действиям. А такие действия уязвимы для описанных проблем. Т.е. большинство раз тест отработает, но могут случиться исключения. Более того, такие неэффективные методы приносят дополнительные достаточно существенные временные затраты. Вот, видимо, такая ненадежность меня и удивила, во время первого опыта.
Именно к этому я и пришел. Большую часть времени разработка проходит в процессе подбора XPath ключей, использовании различных плагинов, файр-багов и обычной JS консоли.
На своем уровне познания Selenium я не смог придумать, как, не изменяя исходные кода веб-клиента, отвязать процесс тестирования от жестких завязок на структуру элементов. Я стараюсь их минимизировать, но идеальная ситуация, когда к любому элементу можно обратиться по уникальному ID. К сожалению, для меня это невозможно. По крайней мере, я не понимаю как это сделать :)