Comments 15
Выглядит не плохо. А какие есть альтернативы ?
Я не знаю прямых альтернатив, и скорее сам не пытался рассматривать все. Но лично если бы я искал альтернативу из готовых решений, то это Katalon Studio
Я бы предложил фреймворк Selenide + Java. Инфа легко гуглится по названию. У нас на его базе написаны сотни UI тестов. Крутятся на Jenkins'e, исполняются на Sauce Labs. Есть проблемы, но примитивные методы типо wait, scrollDown, click уже написаны.
UFO just landed and posted this here
Спасибо за статью, но так и не понял зачем было делать такое? :)
1. ИМХО, все попытки сделать универсальный конвертер из одного в другое (в вашем случае это конвертация xml в команды вебдрайвера) — тупиковая ветка. Вы сами загоняете себя в рамки, обходить которые со временем можно будет только с помощью костылей. Хотя, если ваше приложение особо развиваться не будет, и вам удалось уже на старте предусмотреть все нюансы, то, возможно, решение будет жить долго.
2. Утверждение, что тесты писать быстрее, если они не записаны кодом — сомнительно. Чем оно подкреплено? В коде букв будет меньше, очевидно:
Примерно в 4 раза меньше символов, чем у вас в xml, так еще и проверка есть.
3. Еще минус xml в том, что его трудно читать. YAML получше будет.
4. Ну и CI и Selenium Server нужно на старте закладывать, чтобы потом не было непредвиденных проблем в архитектуре фреймворка.
1. ИМХО, все попытки сделать универсальный конвертер из одного в другое (в вашем случае это конвертация xml в команды вебдрайвера) — тупиковая ветка. Вы сами загоняете себя в рамки, обходить которые со временем можно будет только с помощью костылей. Хотя, если ваше приложение особо развиваться не будет, и вам удалось уже на старте предусмотреть все нюансы, то, возможно, решение будет жить долго.
2. Утверждение, что тесты писать быстрее, если они не записаны кодом — сомнительно. Чем оно подкреплено? В коде букв будет меньше, очевидно:
Тест на java
@Test(dataProvider = "searchKey")
public void searchTest(String searchKey) {
List<GoogleResult> results = googleApp.searchFor(searchKey);
results.forEach(r -> soft.assertThat(r)
.as("Search result is not relevant")
.contains(searchKey)
);
soft.assertAll();
}Примерно в 4 раза меньше символов, чем у вас в xml, так еще и проверка есть.
3. Еще минус xml в том, что его трудно читать. YAML получше будет.
4. Ну и CI и Selenium Server нужно на старте закладывать, чтобы потом не было непредвиденных проблем в архитектуре фреймворка.
Отвечу по пунктам:
1. Мои ивенты — это не конвертация параметров в команды веб-драйвера. Ивент — это целый сценарий, который может быть любым и любого объема и любой сложности. В моем случае это не только селениум — это еще и часть БД. Согласен, что количество типов ивентов может расти, однако я не считаю, что выделение стабильных сценариев и разрастание их количества стоит считать костылем — при грамотном подходе это как рас ведет к уменьшению объема работ при описании теста.
2. Предлагаю Вам все же попробовать мой подход в точности как он описан — я не набираю вручную xml разметку вообще — все что мне нужно сделать — это открыть тег или выбрать параметр из списка доступных — структура строится автоматически + в xml editor наглядно видно всю структуру теста как на ладони — на мой взгляд все же удобнее.
3. Собственно xml — потому что это самый распространенный тип разметки, и о том, как автоматизировать набор структуры xml я имел представления. О наличие подобия XSD схем для YAML я не слышал (возможно они и есть — но я просто взял то что мне ближе — т.е. не выбирал)
4. Полностью согласен, могу лишь оправдаться — условия в компании я описывал, и в настоящий момент мой инструмент — это просто попытка автоматизировать мануальный тест — прога в помощь тестеру.
1. Мои ивенты — это не конвертация параметров в команды веб-драйвера. Ивент — это целый сценарий, который может быть любым и любого объема и любой сложности. В моем случае это не только селениум — это еще и часть БД. Согласен, что количество типов ивентов может расти, однако я не считаю, что выделение стабильных сценариев и разрастание их количества стоит считать костылем — при грамотном подходе это как рас ведет к уменьшению объема работ при описании теста.
2. Предлагаю Вам все же попробовать мой подход в точности как он описан — я не набираю вручную xml разметку вообще — все что мне нужно сделать — это открыть тег или выбрать параметр из списка доступных — структура строится автоматически + в xml editor наглядно видно всю структуру теста как на ладони — на мой взгляд все же удобнее.
3. Собственно xml — потому что это самый распространенный тип разметки, и о том, как автоматизировать набор структуры xml я имел представления. О наличие подобия XSD схем для YAML я не слышал (возможно они и есть — но я просто взял то что мне ближе — т.е. не выбирал)
4. Полностью согласен, могу лишь оправдаться — условия в компании я описывал, и в настоящий момент мой инструмент — это просто попытка автоматизировать мануальный тест — прога в помощь тестеру.
1. Костыли это не разрастание количества сценариев, с этим то как раз все ок. Проблемы будут, когда ваш фреймворк не будет справляться с очередным сценарием. Представьте, что у вас количество типов ивентов дойдет до 100. У вас в коде будет 100 «ифов»?) Не хотел бы я дебажить такой код. Но, повторюсь, не факт, что у вас будут такие проблемы, просто для примера, почему бы и не стал использовать такой подход.
2. Дело вкуса значит, спорить не буду
3. Есть yaml схемы, можно также использовать и json схемы. Но опять же дело вкуса. Мне вообще не нравится как xml выглядит, не отношу его к разряду удобных для чтения человеком.
P.S. кстати, у вас уже есть костыль в вашем решении — теги
2. Дело вкуса значит, спорить не буду
3. Есть yaml схемы, можно также использовать и json схемы. Но опять же дело вкуса. Мне вообще не нравится как xml выглядит, не отношу его к разряду удобных для чтения человеком.
P.S. кстати, у вас уже есть костыль в вашем решении — теги
<orderNumber>1</orderNumber>Да я бы и сам не пользовался, если количество типов было уже больше 20 (хоть и проблему ифов можно решить нехитрой манипуляцией с функциями и хэшмапом))
А про orderNumber ситуация интересней. В далекой первоначальной версии его не было. Это скорее не костыль а такая неприятная издержка. Решил в пользу нее т.к. это немного развязывает руки при манипуляциях в коде и дает стойкое чувство спокойствия за порядок следования.
А про orderNumber ситуация интересней. В далекой первоначальной версии его не было. Это скорее не костыль а такая неприятная издержка. Решил в пользу нее т.к. это немного развязывает руки при манипуляциях в коде и дает стойкое чувство спокойствия за порядок следования.
2. Отказ от использования оберток для селениума.
github.com/PetrovVladimir/SprintAutoTest/blob/master/src/main/java/logic/selenium/SeleniumWrapper.java
Возможно я не проникся, но выглядит как XML'ный ад
я немного не про эти обертки
А по поводу ада… Ну я же не в блокноте работаю — у меня выглядит примерно так:
А по поводу ада… Ну я же не в блокноте работаю — у меня выглядит примерно так:
Надеюсь настанет тот день когда меня перестанут заставлять программировать на xml =)
Вы проделали серьезную работу! Обратите пожалуйста внимание на несколько пунктов:
Думаю ко многим идеям из комментариев вы бы постепенно пришли самостоятельно после определенного количества шишек и граблей — в любом случае удачи! :)
Автотест должен создаваться максимально быстро на сколько это возможно. Если добиться этого качественно, то остальные аспекты, такие как надежность и удобство использования, должны прийти сами собой.Если вы подразумевали под «надежностью» стабильность теста, то к сожалению встречаются ситуации, при которых свинью подкладывает архитектура или реализация тестируемого приложения. Например, зависящая от ветра на Марсе пустая страница после прохождения авторизации:)
Тесты должны быть объявлены декларативно и жить отдельно от кодаВы не смотрели на Cucumber? Его определенно легче читать чем xml, который вам так не нравится.
НЕ оборачивать свою систему в тестовый фреймворкДело ваше, но терять столько готовых плюшек как возможность автоматического перезапуска упавшего теста (для устранения шума), параллельное исполнение тестов из коробки, механизмы группирования тестов для временного отключения, приоритезация исполнения, подготовка данных вне теста, своевременное закрытие сессий WebDriver'a и т.д. просто жалко терять — всетаки советую посмотреть в эту сторону:)
Отказ от использования оберток для селениума.Вам приводили пример Selenid'a: суть не в обретке для обертки, а в уменьшении вашего же когда. Пример — клик по элементу. В классическом Selenium вы руками прописываете метод ожидания видимости (кликабельности) элемента на странице и только потом делаете клик по нему, а здесь просто пишите element.click(), который это сделает для вас.
Красивое оформление результатов не нужно… мне нужно знать 2 вещи: общий результат (положительный/отрицательный), и, если была ошибка – где именно. Возможно еще надо вести статистику.А вот еще одна штука, которую дало бы вам использование фреймворка бесплатно — тоесть даром:) Создаваемые по умолчанию отчеты того же TestNG решают все поставленные вами задачи, а еще и легко интегрируются в CI без единой строчки кода.
Для работы приложения на ПК должен быть установлен браузер FireFox версии выше 52
не баловался с selenium server.Вы совершенно правильно идете — останется только оценить возможности того же Selenoid'a и все закрутится еще интереснее.
Думаю ко многим идеям из комментариев вы бы постепенно пришли самостоятельно после определенного количества шишек и граблей — в любом случае удачи! :)
Sign up to leave a comment.
Создание инструмента для быстрого и эффективного написания автотестов на Selenium