А потом надо обновить браузеры (или какой-то из них сам автоматом обновился) и... "эта песня хороша - начинай сначала". Вам правильно посоветовали селеноид (причем готовые образы даже яндекс-браузера, как вижу, существуют). А еще более правильным бы было иметь минимум UI-тестов и не "набирать их базу". Много UI-тестов - злое зло.
Часты ли у вас баги, которые воспроизводятся только в одном конкретном хромиум-бэйзд браузере? а сколько среди них таких, что могли бы задетектиться вашими авто-тестами?
Как обычно - юзаем webdriver потому что не потрудились сделать приложение тестируемым
Несколько мыслей вслух:
Первое правило оптимизации авто-тестов - выкинуть как можно больше бесполезных UI тестов, особенно таких как на 1-ом скриншоте
Gherkin + json - очень скоро вы будете себя ругать на чем свет стоит
as a side note: зачем вообще тогда нужен геркин? Это все еще человеко-понятный формат у вас там? :)
selenoid в помощь вместо грида, если некритично, что браузеры будут запускаться в докере. Он умеет и в k8s
вместо webdriver при старте чего-то нового рекомендую попробовать playwright - во многих случаях избавляет от головной боли и необходимости писать свою очередную супер-крутую обертку над WD (любители писать слипы точно должны оценить). Ну и море удобных плюшек в комплекте
вообще если хочется много ui-тестов, то можно мокать бэкенд для ускорения / стабилизации
а еще лучше - большую часть тестов сгрузить на нижние уровни. Для тестирования отдельных ui-компонентов и их интеграции (даже в целые страницы) хватает инструментов (например react testing library, под капотом jsdom)
> на тяжёлых страницах (например, список врачей)
звучит так, как лечите симптом. Уменьшить кол-во тестовых данных, оптимизировать перфоманс - не?
> В итоге мы сформировали светофорную систему: от одного до трёх перезапусков для разных типов тестов
аналогично - звучит, как будто лечите симптом. Вообще, можно делать retry как для экшнов так и для проверок прямо в самих тестах (без перезапуска теста целиком)
Вы же сами понимаете, что это так себе ответ. Да, я полагаю, что может быть тысяча причин, почему он может быть против. И спросить разрешения - это простой и правильный подход в цивилизованном обществе.
Все хорошо, только вы описали не фабрику, а частный случай fluent interface. Я еще кое-как соглашусь, что под капотом используется фабричный метод, а вот фабрикой в принципе не пахнет.
А вообще рекомендую впилить IoC контейнер. Решает многие надуманные проблемы.
PS: тесты может и пишутся просто, а вот поддержка тестов с fluent interface может быть очень болезненной.
Подозреваю, что в этом есть какая-то логика, но пока для меня неочевидно, при чем здесь разработка десктоп приложений, сырость и разработка selenium тестов.
Выглядит классно, и идеи интересные.
Получилась эдакая реализация того, что в руби делается через модули. Конечно, некоторые моменты достаточно спорны (получилась-то по сути композиция через наследование интерфейсов), но все равно зачетно.
С одной стороны, вы правы. С другой — попробуйте вспомнить через полгода, как перевести на английский слово «опарыш» :)
Автору:
Код посмотрел по диагонали. Куча анти-паттернов, начиная от повсеместного использования статики и god-object-ов. Классы во многих случаях нужны только чтобы сделать Fishes.CFish is Golec — ну это несерьезно, извините. 80 полей в классе? Ну и все свалено в одну кучу в папку. Про именование, форматирование кода — даже не говорю.
В общем, вы, безусловно, молодец, ибо сделать готовый продукт — очень дорогого стоит. И у вас все получится. Но еще многому надо учиться под присмотром более опытных.
PS: папки bin, obj советую удалять. Им не место ни в архиве, ни в гит.
Не могу быть уверен, что послужило причиной, конечно, но в том же Kubernetes есть стандартные механизмы прокидывания настроек — config maps и secret references — доступ к которым можно получать в т.ч. через переменные окружения. Т.е. подход распространенный в облачном мире, решили упростить жизнь разработчикам.
1. Robot UI у вас вообще вряд ли бы заработал на CI. И параллелизация не при чем. Насчет линукса с фреймбуфером не уверен, а вот на винде в дженкинсе работающем как сервис точно ничего бы не вышло.
Нет, вы не поняли меня. Не надо ничего прокликивать в поисках элемента.
А. Допустим, надо сделать тест: выбрать в дереве элемент (см. UI по ссылке выше), расположенный по след. жестко заданному нами пути: «Project: Testing\Windows\Chrome» и потом еще выполнить какие-то действия. При помощи SpiderTest вы сможете это сделать?
Б. Про какой «нужный элемент» вы говорите, если речь идет про сортировку? Ок, забудем про пагинацию. Есть таблица с данными. Как проверить, что они отсортированы? Проверять сортировку это неправильно и плохо? Это ж первый кандидат на автоматизацию.
В общем, поверьте на слово автоматизатору, который немного уже успел повозиться с не самыми простыми проектами: инструмент годится для очень простых вещей или чтобы показать менеджеру на примере простых страничек, зачем нужна автоматизация. Так сказать, рассчет на вау-эффект. Делать авто-тесты и (главное!) поддерживать их с помощью подобного инструмента — адъ.
А потом надо обновить браузеры (или какой-то из них сам автоматом обновился) и... "эта песня хороша - начинай сначала". Вам правильно посоветовали селеноид (причем готовые образы даже яндекс-браузера, как вижу, существуют).
А еще более правильным бы было иметь минимум UI-тестов и не "набирать их базу". Много UI-тестов - злое зло.
Часты ли у вас баги, которые воспроизводятся только в одном конкретном хромиум-бэйзд браузере? а сколько среди них таких, что могли бы задетектиться вашими авто-тестами?
Как обычно - юзаем webdriver потому что не потрудились сделать приложение тестируемым
Несколько мыслей вслух:
Первое правило оптимизации авто-тестов - выкинуть как можно больше бесполезных UI тестов, особенно таких как на 1-ом скриншоте
Gherkin + json - очень скоро вы будете себя ругать на чем свет стоит
as a side note: зачем вообще тогда нужен геркин? Это все еще человеко-понятный формат у вас там? :)
selenoid в помощь вместо грида, если некритично, что браузеры будут запускаться в докере. Он умеет и в k8s
вместо webdriver при старте чего-то нового рекомендую попробовать playwright - во многих случаях избавляет от головной боли и необходимости писать свою очередную супер-крутую обертку над WD (любители писать слипы точно должны оценить). Ну и море удобных плюшек в комплекте
вообще если хочется много ui-тестов, то можно мокать бэкенд для ускорения / стабилизации
а еще лучше - большую часть тестов сгрузить на нижние уровни. Для тестирования отдельных ui-компонентов и их интеграции (даже в целые страницы) хватает инструментов (например react testing library, под капотом jsdom)
> на тяжёлых страницах (например, список врачей)
звучит так, как лечите симптом. Уменьшить кол-во тестовых данных, оптимизировать перфоманс - не?
> В итоге мы сформировали светофорную систему: от одного до трёх перезапусков для разных типов тестов
аналогично - звучит, как будто лечите симптом. Вообще, можно делать retry как для экшнов так и для проверок прямо в самих тестах (без перезапуска теста целиком)
Имхо - с огроооооомной натяжкой проходит по пункту 1.1. Так как "статья" состоит на 95% из отрывков.
Вы же сами понимаете, что это так себе ответ. Да, я полагаю, что может быть тысяча причин, почему он может быть против. И спросить разрешения - это простой и правильный подход в цивилизованном обществе.
Публикация конечно же согласована с автором книги, я полагаю?
А вообще рекомендую впилить IoC контейнер. Решает многие надуманные проблемы.
PS: тесты может и пишутся просто, а вот поддержка тестов с fluent interface может быть очень болезненной.
Подозреваю, что в этом есть какая-то логика, но пока для меня неочевидно, при чем здесь разработка десктоп приложений, сырость и разработка selenium тестов.
А почему не .net core?
И зачем вам в этот рассадник заразы?
Качество перевода не слишком высоко, прямо скажем. Не обижайтесь, но совсем непонятна аудитория. Мне кажется, что это пустая трата ресурсов и времени.
В принципе, чтение статьи можно закончить на фразе "with a sea of side effects".
Получилась эдакая реализация того, что в руби делается через модули. Конечно, некоторые моменты достаточно спорны (получилась-то по сути композиция через наследование интерфейсов), но все равно зачетно.
habr.com/ru/post/458630/#comment_20354796
Автору:
Код посмотрел по диагонали. Куча анти-паттернов, начиная от повсеместного использования статики и god-object-ов. Классы во многих случаях нужны только чтобы сделать Fishes.CFish is Golec — ну это несерьезно, извините. 80 полей в классе? Ну и все свалено в одну кучу в папку. Про именование, форматирование кода — даже не говорю.
В общем, вы, безусловно, молодец, ибо сделать готовый продукт — очень дорогого стоит. И у вас все получится. Но еще многому надо учиться под присмотром более опытных.
PS: папки bin, obj советую удалять. Им не место ни в архиве, ни в гит.
1. Robot UI у вас вообще вряд ли бы заработал на CI. И параллелизация не при чем. Насчет линукса с фреймбуфером не уверен, а вот на винде в дженкинсе работающем как сервис точно ничего бы не вышло.
2. тянуть jquery — так себе затея. Решение без JQuery гуглится на минут 10 дольше
gist.github.com/druska/624501b7209a74040175
3. использовать еще какую-то библиотеку для xpath? ну хорошо бы залезть в документацию вебдрайвера иногда и узнать, что в executeScript можно передавать WebElement, он будет преобразован в dom-элемент. Обернуть его при помощи JQuery тоже нет проблем
seleniumhq.github.io/selenium/docs/api/java/org/openqa/selenium/JavascriptExecutor.html
4. проблема не то, чтобы частая. Но мы даже своим студентам (точнее будет сказать интернам) даем такое задание.
Integrated tests are scam
А. Допустим, надо сделать тест: выбрать в дереве элемент (см. UI по ссылке выше), расположенный по след. жестко заданному нами пути: «Project: Testing\Windows\Chrome» и потом еще выполнить какие-то действия. При помощи SpiderTest вы сможете это сделать?
Б. Про какой «нужный элемент» вы говорите, если речь идет про сортировку? Ок, забудем про пагинацию. Есть таблица с данными. Как проверить, что они отсортированы? Проверять сортировку это неправильно и плохо? Это ж первый кандидат на автоматизацию.
В общем, поверьте на слово автоматизатору, который немного уже успел повозиться с не самыми простыми проектами: инструмент годится для очень простых вещей или чтобы показать менеджеру на примере простых страничек, зачем нужна автоматизация. Так сказать, рассчет на вау-эффект. Делать авто-тесты и (главное!) поддерживать их с помощью подобного инструмента — адъ.