testomat.io управление авто тестамиВсем привет. Обращаюсь со следующим вопросом: на данный момент прохожу курс автоматизации на java. У нас в компании тесты пишут тоже на этом языке. Есть проблема в следующем. Наши программисты жалуются на то, что тесты написанные на java долго собираются перед запуском, долго крутятся и под них нужно немало серверов,которые стОят денег. Одним из ключевых моментов есть то,что тестировать микросервисы проще на python(якобы под этот язык больше библиотек), а на java нужно устраивать танцы с бубном. На данном этапе мне откровенно все равно на каком языке я их буду писать,т.к. не силен ни в одном из них, но возникает рациональный вопрос: правда ли что тесты на python действительно легче/занимают меньше места на сервере/лучше дружат с микросервисами итд? или нет? Стоит ли по окончанию курса на java переходить всё-таки на python? Лично я бы не очень хотел переходить, т.к. уже имею небольшой опыт написания тестов на java, фрейморк в компании на java, по вакансиям работы больше на java(брал выборку с dou). Буду благодарен за совет,спасибо
Вопрос курсов - отдельный вопрос. Курсы сами по себе дают навыки работы с языком и фреймворком. Но опыт построения фреймворка, опыт тестирования системы и ее автоматизации и решения разнообразных проблем, возникающих при решении этих задач - этот опыт на курсах не получить. Это первое. То есть данный опыт будет ценен при работе с любым фреймворком и любым языком. Поэтому я считаю, что в любом случае вы ничего не теряете с переходом на питон.
Теперь вопрос инструментария. Вы говорите, что в вашей компании фреймворк на джаве, тесты уже есть на джаве, по на джаве. Какие от этого плюсы, очевидно - разработчкики на джаве для вас очень хорошая поддержка, фреймворк уже используется в компании, значит и поддержка фреймворка другими людьми будет, не все на вас одном.
В случае же с выбором другого инструмента. Вы теряете все эти преимущества. Фреймворк будете знать и поддерживать только вы, разрабы вам уже ничем не помогут.
Теперь нам видно, что на самом деле вопрос не только в инструменте, но ещё и в ресурсах вокруг вас. Кроме того, бездумно зарыть потраченные деньги в текущий фреймворк просто банально жалко.
Сейчас необходимо сделать следующее на мой взгляд:
Зарегать все проблемы автотестов в баг трекинг системе. Оповестить ваше начальство о том, что исправление фреймворка необходимо для продолжения работ на нем. Выделить время на исправление проблем:
Рефакторинг архитектуры, распараллеливание тестов (если это гуи, то пример : selenide - независимые агенты с селениумом и т.п.) и т.п.
Не совсем понял про кучу серверов для автотестов, здесь нужно вам понять в чем конкретно проблема с инфраструктурой под ат.
Спасибо большое за совет. А вообще есть какая-либо принципиальная разница между пайтоном и джавой при написании тестов? от чего отталкиваются при выборе языка для написания тестового фреймворка в компаниях?
Конечно есть и разница эта большая. Каждой язык программирования - это свой отельный мир, сообщество, своя культура разработки, где есть свои плюсы, минусы, подходы и решения.
Например, для пайтона есть прекрасный инструмент robot framework для acceptance testing. Для джавы есть похожая тулза, называется jbehave.
Большинство фреймворков реализуют похожий набор функциональности, набор библиотек для обработки данных и работы с различными серверными компонентами, генерация отчётности о прогонах, структура организации тестов в проекте. Но это ещё не всё. Например можно рассмотреть интеграцию отчетности фреймворка contineous Integration сервером. Опыт показывает, что где-то это есть из коробки, а где-то нужно реализовать самому. Пример: для Ruby cucumber опенсурсный кривой форматтер под тимсити. А для robot framework его просто нет, надо самому писать.
Выбор фреймворка должен исходить из реалий твоего проекта и технологического стека в компании в целом. Например, было бы неправильным использовать питон в компании, где его совершенно нигде нет. Это логично, ведь если каждая рабочая группа будет пилить что-то своё, то никакого стека технологий не выйдет, будет полный хаос, на базе этого невозможно создать обмен знаниями по компании. Так как у каждого они будут свои.
Поэтому крайне рекомендуется использовать общий инструмент, дорабатывая его , находя на это ресурсы. А смену этого инструмента нельзя проводить без тщательного сравнения текущего фреймворка с рядом других решений.
Ну и выбор нужно делать так же исходя из архитектуры проекта. Простая архитектура тестится одним простым инструментом. Сложная может включать в себя множество типов тестирования. И для каждого из этих типов должен быть грамотно проработан набор тестов на каждом уровне.
Например, посмотрите не все ваши тесты и спросите, нужны ли они все вам в таком виде?
Пример: вы имеете 1000 гуи тестов.
Как можно было бы изменить подход:
Проверку dynamic gui проводить через модульное Java script тестирование. Это гуи слой без интеграции с бакендом. Далее - отдельные смок тесты на интеграцию гуи с бакендом. Далее- сервисные интеграционные тесты на апи. Далее - юнит тесты в проекте программного обеспечения.
То есть, я хочу таким образом подтолкнуть вас к мысли о том, что возможно все так плохо, медленно, что тесты пишутся одним подходом подряд по всей системе.
Итого:
Инструмент не так важен. Важно, чтобы его использование было удобно и знакомо не только вам, но и всем вашим коллегам. Важно, чтобы вам надо было как можно меньше писать низкоуровневые библиотеки по взаимодействию с вашим ПО, чтобы были пакеты библиотек и они хорошо поддерживались. Важно, чтобы порог входа в инструмент был небольшой. Важно, чтобы инструмент имел возможность интеграции в ci.
Важно провести всестороннее сравнение нескольких инструментов и обсудить это в широком кругу своих коллег.
О каких цифрах речь? Долго - это сколько? Чем собираются тесты? Какие библиотеки они используют для тестирования? Зачем для тестирования микросервисов нужно “немало” серверов? И сколько это - немало? А главное, как python поможет решить вопрос железа?
Или вы не до конца поняли ваших программистов (и проблема лежит гораздо глубже), или у них все настолько плохо, что для решения простых задач приходится создавать тонну костылей. Мне не совсем понятно, о каких танцах речь при работе с микросервисами.
Александр,спасибо,что помогли прояснить ситуацию. У меня параллельно возник еще один вопрос: а бывает на проекте так,что ,к примеру, на гуи тесты пишут на джава, а на какой-то микросервис лучше использовать либу написанную на питоне? такой себе микс технологий, но зато позволяющий ускорить процесс написания тестов. или это бедпрактис?
Не думаю, что это является bad practice. Попробуйте. Но, желательно, чтобы у вас был программный клиент апи к вашему сервису, доступный из ваших тестов. Спросите ваших разработчиков, смогут ли они вам дать xsd описание апи. Иначе, если у вас не будет такой модели, то вам придется ее либо самому руками писать, либо использовать json шаблонизатор для динамических боди. В общем цель в том, чтобы на начальном этапе выбрать такой подход, который максимально избавит от написания каркасного кода и библиотек для взаимодействия с модулями системы.
Попробуйте написать один и тот же тест с post запросом и проверкой данных с вашим текущим кодом на Джава или используя питон. 100% ответа у меня к сожалению нет.