Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

java или python для написания автотестов


(Artem) #1

Всем привет. Обращаюсь со следующим вопросом: на данный момент прохожу курс автоматизации на java. У нас в компании тесты пишут тоже на этом языке. Есть проблема в следующем. Наши программисты жалуются на то, что тесты написанные на java долго собираются перед запуском, долго крутятся и под них нужно немало серверов,которые стОят денег. Одним из ключевых моментов есть то,что тестировать микросервисы проще на python(якобы под этот язык больше библиотек), а на java нужно устраивать танцы с бубном. На данном этапе мне откровенно все равно на каком языке я их буду писать,т.к. не силен ни в одном из них, но возникает рациональный вопрос: правда ли что тесты на python действительно легче/занимают меньше места на сервере/лучше дружат с микросервисами итд? или нет? Стоит ли по окончанию курса на java переходить всё-таки на python? Лично я бы не очень хотел переходить, т.к. уже имею небольшой опыт написания тестов на java, фрейморк в компании на java, по вакансиям работы больше на java(брал выборку с dou). Буду благодарен за совет,спасибо


(Александр Илюшкин) #2

Вопрос курсов - отдельный вопрос. Курсы сами по себе дают навыки работы с языком и фреймворком. Но опыт построения фреймворка, опыт тестирования системы и ее автоматизации и решения разнообразных проблем, возникающих при решении этих задач - этот опыт на курсах не получить. Это первое. То есть данный опыт будет ценен при работе с любым фреймворком и любым языком. Поэтому я считаю, что в любом случае вы ничего не теряете с переходом на питон.

Теперь вопрос инструментария. Вы говорите, что в вашей компании фреймворк на джаве, тесты уже есть на джаве, по на джаве. Какие от этого плюсы, очевидно - разработчкики на джаве для вас очень хорошая поддержка, фреймворк уже используется в компании, значит и поддержка фреймворка другими людьми будет, не все на вас одном.

В случае же с выбором другого инструмента. Вы теряете все эти преимущества. Фреймворк будете знать и поддерживать только вы, разрабы вам уже ничем не помогут.

Теперь нам видно, что на самом деле вопрос не только в инструменте, но ещё и в ресурсах вокруг вас. Кроме того, бездумно зарыть потраченные деньги в текущий фреймворк просто банально жалко.

Сейчас необходимо сделать следующее на мой взгляд:

Зарегать все проблемы автотестов в баг трекинг системе. Оповестить ваше начальство о том, что исправление фреймворка необходимо для продолжения работ на нем. Выделить время на исправление проблем:

Рефакторинг архитектуры, распараллеливание тестов (если это гуи, то пример : selenide - независимые агенты с селениумом и т.п.) и т.п.

Не совсем понял про кучу серверов для автотестов, здесь нужно вам понять в чем конкретно проблема с инфраструктурой под ат.


(Artem) #3

Спасибо большое за совет. А вообще есть какая-либо принципиальная разница между пайтоном и джавой при написании тестов? от чего отталкиваются при выборе языка для написания тестового фреймворка в компаниях?


(Александр Илюшкин) #4

Конечно есть и разница эта большая. Каждой язык программирования - это свой отельный мир, сообщество, своя культура разработки, где есть свои плюсы, минусы, подходы и решения.

Например, для пайтона есть прекрасный инструмент robot framework для acceptance testing. Для джавы есть похожая тулза, называется jbehave.
Большинство фреймворков реализуют похожий набор функциональности, набор библиотек для обработки данных и работы с различными серверными компонентами, генерация отчётности о прогонах, структура организации тестов в проекте. Но это ещё не всё. Например можно рассмотреть интеграцию отчетности фреймворка contineous Integration сервером. Опыт показывает, что где-то это есть из коробки, а где-то нужно реализовать самому. Пример: для Ruby cucumber опенсурсный кривой форматтер под тимсити. А для robot framework его просто нет, надо самому писать.

Выбор фреймворка должен исходить из реалий твоего проекта и технологического стека в компании в целом. Например, было бы неправильным использовать питон в компании, где его совершенно нигде нет. Это логично, ведь если каждая рабочая группа будет пилить что-то своё, то никакого стека технологий не выйдет, будет полный хаос, на базе этого невозможно создать обмен знаниями по компании. Так как у каждого они будут свои.

Поэтому крайне рекомендуется использовать общий инструмент, дорабатывая его , находя на это ресурсы. А смену этого инструмента нельзя проводить без тщательного сравнения текущего фреймворка с рядом других решений.

Ну и выбор нужно делать так же исходя из архитектуры проекта. Простая архитектура тестится одним простым инструментом. Сложная может включать в себя множество типов тестирования. И для каждого из этих типов должен быть грамотно проработан набор тестов на каждом уровне.

Например, посмотрите не все ваши тесты и спросите, нужны ли они все вам в таком виде?

Пример: вы имеете 1000 гуи тестов.
Как можно было бы изменить подход:

Проверку dynamic gui проводить через модульное Java script тестирование. Это гуи слой без интеграции с бакендом. Далее - отдельные смок тесты на интеграцию гуи с бакендом. Далее- сервисные интеграционные тесты на апи. Далее - юнит тесты в проекте программного обеспечения.

То есть, я хочу таким образом подтолкнуть вас к мысли о том, что возможно все так плохо, медленно, что тесты пишутся одним подходом подряд по всей системе.

Итого:

Инструмент не так важен. Важно, чтобы его использование было удобно и знакомо не только вам, но и всем вашим коллегам. Важно, чтобы вам надо было как можно меньше писать низкоуровневые библиотеки по взаимодействию с вашим ПО, чтобы были пакеты библиотек и они хорошо поддерживались. Важно, чтобы порог входа в инструмент был небольшой. Важно, чтобы инструмент имел возможность интеграции в ci.
Важно провести всестороннее сравнение нескольких инструментов и обсудить это в широком кругу своих коллег.


(Sergey Korol) #5

О каких цифрах речь? Долго - это сколько? Чем собираются тесты? Какие библиотеки они используют для тестирования? Зачем для тестирования микросервисов нужно “немало” серверов? И сколько это - немало? А главное, как python поможет решить вопрос железа?

Или вы не до конца поняли ваших программистов (и проблема лежит гораздо глубже), или у них все настолько плохо, что для решения простых задач приходится создавать тонну костылей. Мне не совсем понятно, о каких танцах речь при работе с микросервисами.


(Artem) #6

Александр,спасибо,что помогли прояснить ситуацию. У меня параллельно возник еще один вопрос: а бывает на проекте так,что ,к примеру, на гуи тесты пишут на джава, а на какой-то микросервис лучше использовать либу написанную на питоне? такой себе микс технологий, но зато позволяющий ускорить процесс написания тестов. или это бедпрактис?


(Александр Илюшкин) #7

Не думаю, что это является bad practice. Попробуйте. Но, желательно, чтобы у вас был программный клиент апи к вашему сервису, доступный из ваших тестов. Спросите ваших разработчиков, смогут ли они вам дать xsd описание апи. Иначе, если у вас не будет такой модели, то вам придется ее либо самому руками писать, либо использовать json шаблонизатор для динамических боди. В общем цель в том, чтобы на начальном этапе выбрать такой подход, который максимально избавит от написания каркасного кода и библиотек для взаимодействия с модулями системы.

Попробуйте написать один и тот же тест с post запросом и проверкой данных с вашим текущим кодом на Джава или используя питон. 100% ответа у меня к сожалению нет.


(Oleksii Ihnatiuk) #8

Мой совет - начните писать!
Второй совет - подумайте о том, что написал @ArtOfLife