Язык программирования для Automation

Привет. Столкнулся с дилеммой

Работаю как мануальщик. Давно поглядываю в сторону автоматизации

Но к сожалению не могу определить язык для автоматизации

Есть два варианта который в наших широтах популярны для AQA Java и Python

Уровень вхождения не пугает, так как в свое время мучал любительски C# и Java

Есть три волнующих вопроса.

1. Судя по многим (в том числе забугорным) сайтам вакансий пайтон более встречается на западе. Но у нас в небольшом отрыве все же Java. Все же как я понял из гугления, селениуму в целом без разницы с каким их языков работать ?
2. На ваших проектах QA пишут тесты на языке основного проекта ?
3. С точки зрения перспективности на будущее. Похоже что в основном python используют в большей степени для web и machine learning. Но есть ли возможности использовать его, в других сферах ?

👍НравитсяПонравилось1
В избранноеВ избранном1
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Если под автоматизацией подразумеваются web UI и, может быть, web API тесты, то особой разницы нет, и для Java, и для Python, и для JS/TS есть хороший инструментарий и комьюнити. Если же хотите шагнуть в сторону от веб, то Python вне конкуренции.

Через пол года будет новый.. Здесь начал выкладывать. www.facebook.com/groups/1084931979000426

Не понимаю зачем джава когда можно выбрать питон

Ничего страшного, никто не идеален

2. Был проект, где основа Java, а тесты на Python, даже 2 таких вспомнил. Не понимаю зачем так делали и сами объяснить не смогли.
Был проект основной код на С++, тесты на Python
3.

web и machine learning

 +QA автоматизация. Другие сферы это какие?

Хлопче, бери Java та не мучайся — завжди буде копiйчина на хлiб та масло. Якщо треба UI — selenide.org, кращого рiшення не знайдеш

Пишу на TypeScript. Очень мне заходит типизированный JS )
1. Не особо слежу за вакансиями, но думаю, что JS, Java, Python вполне популярны.
2. Что есть язык основного проекта? Бек, фронт? Зачем писать на стеке основного проекта? Бытует мнение, что девелоперы могут помогать. Так обычно не происходит. У них нет опыта в e2e тестах и нет понимание, какие проблемы там встречаются и как обычно их решают.
3. Python ещё на биг дата фигурирует. Думаю, девопсы с ним ещё дружат. Снова про своё болото — на js пишут бек, фронт, мобайл и десктоп. Популярность растёт постоянно.
PS. некоторые вещи лучше делать через execute скрипта на тороне браузера. А туда ты можешь запихнуть только JS.

7 лет опыта в комменте написать?

Хоча би наприклад, не стикався з e2e тестами, тому цікавлюсь

Самая большая проблема — это дизайн решения. Часто бывает делают пейдж обджекты и начинается каша в наследовании (пример решения можно здесь посмотреть www.youtube.com/watch?v=Vx1mO5tw3HE). Куча проблем с ожиданиями. Где-то элемент подгружается быстрее, где-то медленнее. Главное не начать использовать слипы ) Ряд проблем с тест раннером можно здесь посмотреть: www.youtube.com/watch?v=N4bHBhrZhiI
Часто бывают проблемы со скоростью. Принято считать UI тесты медленными, но они реально очень быстрые по сравнению с юзером. При переходе на страницу бывает тест кликает на кнопку, которая ещё не готова для этого клика (что-то, что влияет на кнопку недорендерилось). Тест падает, а руками повторить никто не может.
Это то, что первое в голову пришло.

Главное не начать использовать слипы )

"Класичне" рішення з wait_for_element — це while зі сліп на 1 сек і перевірка чи елемет з’явився
XD

У многих инструментов есть свои встроенные вейтеры. Главное — правильно их использовать. Плюс, если в инструменте есть ещё неявные ожидания, то нужно понимать, как они взаимодействуют с явными (dou.ua/forums/topic/20115). Ну и не всегда достаточно просто подождать одного элемента.

есть свои встроенные вейтеры

І внутрях у них отой while 1

Ну и не всегда достаточно просто подождать одного элемента.

Коли таке починається треба зупинитись і переписати простіше

Когда такое начинается — надо определить куда такая сложность пойдёт. т.к., если сложность есть, то её всё равно надо будет куда-то деть. Нельзя любую задачу решить просто.

Но у нас в небольшом отрыве все же Java

Отрыв очень небольшой, а иногда вообще незаметный.
И это притом что еще не так давно Java была неоспоримым лидером в QA automation, Java-вакансий было во много раз больше чем на Python (а JS был вообще незаметен).
Сейчас же примерно одинаковое количество вакансий по Java, JS, Python. То есть доля Java с порядка 90% снизилась где-то до 30%
Текущие результаты поиска вакансий в разделе QA — jobs.dou.ua/vacancies/?category=QA

ЯзыкОбычный поискВ описаниях
Java54256
Python45173
JavaScript16+23(JS)157+152(JS)
«JavaScript» и «JS» могут быть одновременно в вакансиях так что цифры поменьше будут чем сумма (особенно в описаниях вакансий).
Но к сожалению не могу определить язык для автоматизации

Рекомендую Python.

  • Как язык очень хорош, приятнее на нем писать.
  • При обучении, особенно с нуля (или если забыл что ранее учил) — легче и интереснее, меньше шансов что забьешь на учебу.
  • На небольших проектах может быть в разы меньше строк кода чем на Java, и соответственно меньше времени тратится на написание кода.
  • На больших проектах Java предпочтительнее — но сомневаюсь что что-то большое будет в QA automation
  • Мне нравится работать с Selenium в консоли. Не нужно возиться с присоединением к браузеру, один раз запустил Selenium, а потом код можно построчно отлаживать.
    В Java такое невозможно.
JS вообще не рассматриваю как вариант работы с Selenium, мне хватило просмотров примеров , как то все коряво (в дополнение к общей корявости JS). По моему место JS — в браузере, в все остальное извращение.

Я такое не пробовал, но подозреваю что гораздо менее удобно чем консоль.
Работая в консоли с селениум, создаю переменные, которые должны быть видны при следующем выполнении кода в консоли, без этого вообще никак.
Будут ли видны переменные при запуска кода Java в редакторе?
К тому же возможно что это работает только в IntelliJ IDEA
Да и судя по описанию, даже если переменные сохраняются, все равно очень неудобно — это не консоль.

Не надо подозревать — нужно просто попробовать. Вы там можете писать что угодно и выполнять что угодно — выполнение теста не прервётся в случае ошибки и это офигенно упрощает жизнь при написании тестов.

К тому же возможно что это работает только в IntelliJ IDEA

Это работает во всех продуктах от Jetbrains.

Не надо подозревать — нужно просто попробовать.

Не вижу смысла. Для меня Java умер как только я освоил Python :-)
И как бы там ни было, консоль гораздо удобнее выполнения кусочков кода в отдельных окнах.

Голосую за Javascript + Cypress. На Selenium писать тесты не удобно, как и дебажить. На любом языке. Хотя в легаси проектах его наверное очень много и кому-то этим нужно заниматься.

P.S. не QA

Cypress создавался, как инструмент для юнит и интеграционных тестов. Делал на нём e2e тесты года 4 назад — то ещё удовольствие. Для большого проекта имхо не подходит для e2e тестов. А на селениуме и щас много новых проектов пишутся. Везде свои +/-, надо исходить из задач проекта и селениум всё ещё весьма хорошо подходит под большинство проектов.

В чем было неудовольствие в тестах на Cypress 4 года назад?

Я уже детали не вспомню. Специально написал, что давно было, бо, может, щас по-другому. По моему мнению для больших e2e UI проектов отлично подходят паттерны page object, page elements и всё, что с ними связано. На сайпресе это было делать крайне неудобно. Он всей своей апихой говорил, что создан для юнит тестов. Ну и плюс я тогда в сайпрес баг постил больше, чем в свой проект.

Понятно

Но вроде в cypress вполне можно пользоваться Page object паттерном, хотя не рекомендуется

Для мне киллер фича сайпресса в том что можно визуально пройтись по каждому этапу в тесте, что делает написание и дебаг тестов очень удобным. Может в селениуме что-то придумал но когда я раньше им пользовался это было очень не удобно — чтобы понять что упало, чаще всего нужно было перезапускать, смотреть логи, плюс динамично генерируемые контент(в смысле не server-side) он довольно часто не стабильно проверял, постоянно в рандомных местах падало.

Как по мне то, что они предлагают хуже расширается. Мне ещё очень нравится подход с lazy elements, который был у протрактора. Я себе такое сам доделал в wdio и радуюсь жизни )
То, что можно пошагово пройтись по тесту и посмотреть состояние дома в любой момент — это круто, вопросов нет. Но всё остальное мне не заходит :) Ни в коем случае не пытаюсь убедить никого с ним не работать, каждому своё и у каждого свой опыт. Я делюсь своим.
У меня каждое действие логгируется автоматически. Понять по логам, что и где пошло не так очень просто. В момент падения теста берётся скриншот. Ночные тесты записывают видосы. С дебагом проблем не возникает.

Та вже Playwright краще певно, зараз дуже хвалять його

Хоч і сам пишу на Java, але якщо б зараз починав, то напевно вибрав би JS (не беремо до уваги ООП vs ФП)
Думаю, що C# точно ні, вакансій дуже мало, а перспектив ще менше.

1. Selenium — так, в принципі без різниці, хоч і найпершими виходять байндінги якраз на Java, а потім вже на все інше — тобто, невеликий плюс, що нові версії швидше виходитимуть порівняно з іншими платформами
2. Java (хоча є кілька на JS)
3. за перше місце будуть боротись JS і Java. Python дуже повільний порівняно з Java (не знаю за JS, але підозрюю, що теж)

Також перевага писати Java в тому, що потім легко почати писати Performance тести, бо одні з найпопулярніших рішень якраз таки JDK-based — JMeter і Gatling, який на Scala.

Тому раджу вибирати тільки між Java і JS.

1. Як на мене, за останній рік-два дуже додав JS, а пайтон програє всім, за винятком хіба що рубі, тобто десь так JS > Java/C# > Python > Ruby

Все же как я понял из гугления, селениуму в целом без разницы с каким их языков работать ?

Селеніум сам по собі всього лиш бібліотека, (хоча навіть там є нюанси, напр. враппер Selenide для джави досить поширений, тоді як його пайтонівський аналог Selene практично мертвий), різниця існує вже на рівні самих фрейморків.
Інша справа, що хоч це і значна її частина, однак автоматизація це не тільки ’написання функціональних автотестів для FE на селеніумі’, інші компоненти, як і нефункціональні тести, теж успішно автоматизуються, там нюансів і різниці в лібах та фреймворках побільше
2. Поширена практика, але так не завжди, є купа інших факторів, які впливають на вибір
В першій конторі так було, але бачив також варіант, коли автоматизація почалась як приватна ініціатива від самого QA і він вибрав python, бо знав тільки його
Зараз відрізняється, бо для тестів потрібен специфічний клієнтський фреймворк від потрібні задачі, існує лише для пайтона
3. Є, в Україні є компанії які зараз використовують для автотестів напр. firmware, мережного обладнання, контролерів і т.д.(це правда в рази складніше, ніж селеніум)
А так то «С точки зрения перспективности на будущее.» то однозначно JS

в якості мови в AQA вакансіях
на entry рівнях теж в більшості бекграунд пишуть Java/C#, той же SS веде свої AQA/SDET курси на Java/C# в переважній більшості якщо не помиляюсы т.д.

Тобто на java НЕ веб проекті може бути жс — як ЯП для тестів?

мабуть ні
однак не зовсім зрозуміло, як це питання пов’язується з кількістю AQA вакансій на пайтоні, про що велася мова з самого початку

До чого?
Я просто намагаюсь зібрати твердження в щось когерентне

Як на мене, за останній рік-два дуже додав JS, а пайтон програє всім, за винятком хіба що рубі, тобто десь так JS > Java/C# > Python > Ruby

+

в більшості бекграунд пишуть Java/C#

+
те що аутсорс все ж таки більше не веб орієтований

І зібрати все це в мене, щось не виходить

— кількість js AQA вакансій значно зросла за останні пару років і вища, ніж кількість python AQA вакансій, по java/c# теж більше пропозицій за python
— в інтерн вакансіях або manual + automation частіше зустрічається java/c#/js у таких пунктах як basic programming skills чи experience with automated testing і т.п.
— останнє твердження невідомо звідки взято взагалі, веб проектів на аутсорсі у нас більше, звідси і розклад по мовах з п.1

за останній рік-два дуже додав JS

не знаю що там JS додав, але писати тести на JS так само боляче як 2, 3, 4 роки тому. Беремо асинхронну мову програмування i стрiляючи собi в ноги пишемо синхроннi тести через страждання та бiль.
Краще за Selenide наврядчи щось напишуть.

Подписаться на комментарии